Hi Florian,
can I ask what your interest in AEAD is? Is there a particular
application that you have in mind?
DJ provided a good summary of CCM and GCM. To add some follow-on to
that, RFC 5116 defines an interface to an AEAD algorithm, and a
registry of such algorithms. TLS 1.2 ties into this interface, though
currently only GCM is defined in TLS. Both GCM and CCM are defined
for use in IPsec, and GCM is in Suite B.
The other AEAD algorithm that's been defined is SIV mode; AFAIK it has
not been in any standards to date.
On Jul 14, 2010, at 10:22 AM, [email protected] wrote:
What's the current state of affairs regarding combined encryption and
authentication modes?
I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I
couldn't find test vectors),
The motivations for aead-aes-cbc-hmac-sha1 were 1) to match "legacy"
situations in which only the older algorithms are available, and 2) to
define an AEAD algorithm that does not need a unique IV (a
"randomized" algorithm in the terms of RFC5116). The draft could
probably be re-spun to better meet goal #1, though I am not sure how
important that goal is. In general, it would be valuable to have a
randomized algorithm, though it would be preferable to have one that
met the higher performance standard of GCM, which anything CBC based
won't meet.
More recently Justin Troutman has expressed an interest in possibly
carrying forward work on generic composition; I've copied him.
but I later came across CCM and EAX. CCM
has the advantage of being NIST-reviewed. EAX can do streaming (but
that's less useful when doing authentication). Neither seems to be
widely implemented. But both offer a considerable reduction in
per-message overhead when compared to the HMAC-SHA1/AES combination.
Are there any other alternatives to consider? Are there any traps I
should be aware of when implementing CCM?
--
Florian Weimer <[email protected]>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
[email protected]
CCM is widely implemented. It's a matter of where you look.
Down at the MAC layer, AES-CCM has proved popular in wireless packet
communication because it is well adapted for separating the
treatment of
the header as plaintext AAD from the packet body as ciphertext. Also
it is
relatively efficient to implement in hardware since it relies only
on a
single AES encrypt block cipher and the birthday resistance of the
ciphertext MAC reduces on-air per packet overhead. This is the why for
example that you see AES-CCM in wireles USB, 802.11, 802.16 and WiMAX
management protocols.
A couple of years after 802 went for AES-CCM, AES-GCM became the
802.3/ethernet choice since it is more parallelizable and so can be
implemented for 10Gbps+ links where CCM becomes trickier. The per
packet
overhead is higher, but bandwidth on wires is cheap.
I don't think you can really implement CCM except in the context of
a more
detailed specification for a protocol. CCM is a flexible
specification and
protocols that use it must nail down a number of parameters and field
sizes in order to be interoperable. It's not so easy to just plug it
in
which makes is less convenient for the more pluggable software based
protocols higher up the stack.
That's true, though there are some particular CCM parameter choices
made in http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml
Some technically good candidates for standards adoption, E.G. OCB met
resistance due to licensing issues.
OCB is very attractive in software, but GCM is more efficient in
hardware because it can be implemented without pipeline stalls. GCM
can perform well in software, though it can't be as compact as CCM,
and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest
hardware support like Intel's new PCLMULQDQ instruction (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3
).
regards,
David
DJ
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
