Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

[Michael Clark <[e-mail]>]

On 24/12/14 2:15 pm, Peter Gutmann wrote:
> Michael Clark <[e-mail]> writes:
> 
>> I have been doing some independent research on TLS AEAD ciphers and decided
>> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM
> 
> If you're going to look at these, what about also looking at encrypt-then-MAC,
> which is another AEAD mechanism?

What prompted me to do the analysis of AEAD ciphers was this:

    https://www.imperialviolet.org/2014/12/08/poodleagain.html

"This seems like a good moment to reiterate that everything less than
TLS 1.2 with an AEAD cipher suite is cryptographically broken"

This statement isn't strictly true. Agreed. CBC mode with AD and MAC is
a form of AEAD.

I am aware CBC mode was vulnerable due to implementation bugs in the
handling of padding not just in SSLv3.0 but also more recently in a
particular TLS implementation.  However an encrypt-then-MAC AD plus
cipher text (with arbitrary MAC) is not strictly equivalent to an AEAD
cipher both from a layering perspective and from the collision proof of
cipher based MACs and design respect to padding; such as AEAD_AES_EAX
and AEAD_CHACHA20_POLY1305. AEAD_AES_GCM implementations had padding
bugs too (Fragility of AES-GCM, Gueron). I guess it's a layering issue
and a matter of pushing AEAD into the cipher.

I understand there is a difference in Cipher based MACs and PRF based
MACs which is the difference between birthday attacks and reversing
cipher rounds vs finding collisions.

Poly1305 has a similar proof to EAX as it is a cipher based MAC,
originally AES and now CHACHA20

http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04

>From a protocol design perspective (irrespective of TLS) it would be
desirable to having AEAD at the one layer as it would allow for
specification and implementation simplicity and symmetry, rather than
have it duplicated at the TLS implementation layer for some ciphers and
not for AEAD ciphers e.g. AEAD_AES_GCM, AEAD_AES_CCM, AEAD_AES_EAX and
AEAD_CHACHA20_POLY1305, etc. There is no reason why TLS implementations
couldn't support TLSv1.2 to maintain CBC mode and just have AEAD
ciphers. If TLSv1.3 only supported AEAD ciphers then a TLSv1.3
implementation would be simpler. Simplicity and composability between
layers is a good property.

I also saw the post about removing the MAC from the TLS cipher names as
they are now included in "signature_algorithms" since TLSv1.2. This
makes a lot of sense. I am aware some of the earlier TLS "features" were
vestiges of "export controls" i.e. mechanisms to lower cipher strength
based on the the certificate. I remember the days of SGC...

However that brings me back to the point before about all of the current
AEAD ciphers have an 128 bit auth tag (due in part to their proof of
non-collision as cipher-based MACs). I don't think this is a major issue
due to the nonce lifespan; except for highly parallelizable AEAD schemes
such as AEAD_AES_GCM (for reasons I noted). Given proof of no
key-independent collisions, then the bit strength of cipher based MACs
must be higher than one-way hashes without no-collision proofs.

If I were to choose, I'd go for symmetry and start thinking about 256
and 512 bit blocks, so the AEAD tag would be extended this way. But that
is futures. We don't have the ciphers. These all have 128 bit tags:

    AEAD_AES_GCM
    AEAD_AES_CCM
    AEAD_AES_EAX
    AEAD_CHACHA20_POLY1305

Then we couldn't use SHA256 and SHA384 to mitigate attacks on data
integrity (tag collisions) in AAED ciphers.

In this case the super-symmetry would be to allow CBC style MAC optional
on AEAD ciphers and mandatory on non-AEAD ciphers like CBC.

AES_256_GCM + SHA256 would mitigate the integrity risk of 128-bit tags.
Thanks for prompting the thought. AES_256_GCM 128-bit tags may be more
vulnerable to integrity attacks (bit errors) than AES_256_CBC with
SHA384 MACs.

These would both have 384 bits tags (with a super symmetry design):

AES_256_GCM + SHA256
AES_256_CBC + SHA384

Michael.