Adding TLS 1.2 Support to Your TLS Library - Implementing SSL/TLS Using Cryptography and PKI - page 523

This implementation of AEAD is crucially fl awed, though. It does exactly
what I warned you earlier to never ever do, which is to reuse a nonce. There's no
provision here to ever change the IV; because each call to aead_encrypt starts
the nonce counter back over at 0, every record is encrypted with the same set
of input. You can't let the counter run over from one record to the next, either.
The other end fails to decrypt the message because the receiving code expects to
start over from 2 (or 1, or whatever) at decryption time. However, the 12 bytes of
nonce are controlled entirely by the sender. There's nothing stopping you from
making the last four bytes of the nonce itself another counter, whose values
do persist from one aead_encrypt to the next. In fact, you could go ahead and
safely use the MAC sequence_num for exactly this purpose.
AES-CCM has not yet been assigned a cipher suite identifi er in the TLS space;
when and if such an identifi er is assigned, its use would be exactly like the
AES-GCM example shown here.
In actual practice, AEAD ciphers don't offer much benefi t over block ciphers
with strong MAC functions when implemented in software. Most of the interest
in these ciphers surrounds dedicated hardware. AES-GCM can be parallelized to
encrypt 10Gbps, which is more than enough to encrypt an HDMI video stream
in real time. Intel's newest processors include a PCLMULQDQ instruction that is
explicitly stated as being an optimization to support AES-GCM. Expect AEAD
ciphers to be of great interest to embedded hardware implementers.
Working ECC Extensions into the TLS Library
Strictly speaking, ECC is not unique to TLS 1.2; AEAD is, but ECC is not. Although
TLS 1.2 is the fi rst version of TLS to mention ECC specifi cally, RFC 4492, which
defi nes the ECC extensions to TLS, was written with TLS 1.1 in mind. In fact,
OpenSSL version 1.0, which was released in March of 2010, supports RFC 4492
ECC extensions but does not support TLS 1.1. Make sure that you have a good
grasp of the ECC concepts presented in Chapters 3 and 4 before reading this
section.
Recall that ECC is mostly of interest for public-key operations; ECC operations
are used to exchange a symmetric key and validate signatures, but plain-old
AES usually takes over from there. Key exchange is done via elliptic-curve Diffi e-
Hellman (ECDH), and signatures are verifi ed using elliptic-curve DSA (ECDSA).
ECDH is analogous to integer Diffi e-Hellman. Integer Diffi e-Hellman has
both sides agree on a starting point — an integer — and each side raises it to
an arbitrary (secret) power, exchanging the results with one another. Each side
then raises the result by the secret. The distributivity of exponentiation guar-
antees that each side arrives at the same answer; the diffi culty of the discrete