[145364] in cryptography@c2.net mail archive
Re: Encryption and authentication modes
daemon@ATHENA.MIT.EDU (David McGrew)
Thu Jul 22 17:51:37 2010
From: David McGrew <mcgrew@cisco.com>
To: dj@deadhat.com, Florian Weimer <fweimer@bfk.de>
In-Reply-To: <021272feaa93e4760c2a3b5b8c65af71.squirrel@deadhat.com>
Date: Thu, 22 Jul 2010 13:27:28 -0700
Cc: Cryptography List <cryptography@metzdowd.com>,
Justin Troutman <justin@extorque.com>
Hi Florian,
can I ask what your interest in AEAD is? Is there a particular =20
application that you have in mind?
DJ provided a good summary of CCM and GCM. To add some follow-on to =20
that, RFC 5116 defines an interface to an AEAD algorithm, and a =20
registry of such algorithms. TLS 1.2 ties into this interface, though =20=
currently only GCM is defined in TLS. Both GCM and CCM are defined =20
for use in IPsec, and GCM is in Suite B.
The other AEAD algorithm that's been defined is SIV mode; AFAIK it has =20=
not been in any standards to date.
On Jul 14, 2010, at 10:22 AM, dj@deadhat.com 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" =20
situations in which only the older algorithms are available, and 2) to =20=
define an AEAD algorithm that does not need a unique IV (a =20
"randomized" algorithm in the terms of RFC5116). The draft could =20
probably be re-spun to better meet goal #1, though I am not sure how =20
important that goal is. In general, it would be valuable to have a =20
randomized algorithm, though it would be preferable to have one that =20
met the higher performance standard of GCM, which anything CBC based =20
won't meet.
More recently Justin Troutman has expressed an interest in possibly =20
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 <fweimer@bfk.de>
>> BFK edv-consulting GmbH http://www.bfk.de/
>> Kriegsstra=DFe 100 tel: +49-721-96201-1
>> D-76133 Karlsruhe fax: +49-721-96201-99
>>
>> ---------------------------------------------------------------------
>> The Cryptography Mailing List
>> Unsubscribe by sending "unsubscribe cryptography" to
>> majordomo@metzdowd.com
>>
>
> 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 =20
> treatment of
> the header as plaintext AAD from the packet body as ciphertext. Also =20=
> it is
> relatively efficient to implement in hardware since it relies only =20
> 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 =20
> packet
> overhead is higher, but bandwidth on wires is cheap.
>
> I don't think you can really implement CCM except in the context of =20=
> a more
> detailed specification for a protocol. CCM is a flexible =20
> 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 =20=
> 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 =20
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 =20
hardware because it can be implemented without pipeline stalls. GCM =20
can perform well in software, though it can't be as compact as CCM, =20
and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest =20
hardware support like Intel's new PCLMULQDQ instruction =
(http://www.drdobbs.com/security/218102294;jsessionid=3DGMTY4RCFLHBMRQE1GH=
OSKHWATMY32JVN?pgno=3D3=20
).
regards,
David
> DJ
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to =
majordomo@metzdowd.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
