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

Michael Clark <> Wed, 24 December 2014 08:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D15F01AD002 for <>; Wed, 24 Dec 2014 00:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.068
X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VfkuUeOIkf0m for <>; Wed, 24 Dec 2014 00:59:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB2AA1ACFF6 for <>; Wed, 24 Dec 2014 00:59:26 -0800 (PST)
Received: from monty.local ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id sBO9K6Yv009938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Dec 2014 09:20:09 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=klaatu; t=1419412813; bh=CMZfkKhtgqBLrPihZjlBrJmF2V0FLlz6QzDhGyeAvZE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gQBfn3A7iqUahWtzcAmTTcN93AHU2mkzIwKvxhxa0PaWAasMqW3Iu0Lro0FRUzPuA zHGgoZV1AgH+qzMvYnuRaX5Tb0+MgZkgQOOtu/gBJdMD1yNySopOhB5it0vxnsOVj6 hoz2os+YA5jsIORUURskTGNzVOb5PfptD2hRRmRQ=
Message-ID: <>
Date: Wed, 24 Dec 2014 16:58:54 +0800
From: Michael Clark <>
Organization: Metaparadigm Pte Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Peter Gutmann <>, "<>" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at
X-Virus-Status: Clean
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Dec 2014 08:59:29 -0000

On 24/12/14 2:15 pm, Peter Gutmann wrote:
> Michael Clark <> 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:

"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

>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:


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