Encryption and authentication modes

[David McGrew]

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, dj at 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"  
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                <fweimer at bfk.de>
>> 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
>> majordomo at 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  
> 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 majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com