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

Watson Ladd <> Thu, 25 December 2014 01:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 98C7F1A6F8C for <>; Wed, 24 Dec 2014 17:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rOnGLvmWHNX3 for <>; Wed, 24 Dec 2014 17:57:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 653791A6F88 for <>; Wed, 24 Dec 2014 17:57:01 -0800 (PST)
Received: by with SMTP id t59so4344337yho.19 for <>; Wed, 24 Dec 2014 17:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pHDwrFjvkaoNR1SNFzXzHZ5+vIsgd8iTMFbak6Z1nm0=; b=OjQZS4B3HRP5QokYqB6DWfmX+1OX/ntuzYv8liqciy8J0eX53KY9NSJyTqo1XaJimn d/HjT2FB4ryqOSOMLO79aEOReIhbvHQXt0TIN8MRqMjiJmwP2ur4pu+gHY6GdDMyCJT9 MhRmegVUg9J9vocwyFdVvfkREpNwnUq41FK932MH6JRVP6IzIE6qF+9TFA7PmWJSyM7A cDX435ztvfniY3XYQSIj4JqE+Pna8L3GyaTAgplnK9iEuFAm9EKseMt4oyU4mvx/8bzo aRVjs9VuT3ppLcygjRbgjuTtYzd5zdPM2Hq68HQzs2AoexO/vR1O5StWrYLqL8WvYHti wBiQ==
MIME-Version: 1.0
X-Received: by with SMTP id s24mr28748564yhs.138.1419472620561; Wed, 24 Dec 2014 17:57:00 -0800 (PST)
Received: by with HTTP; Wed, 24 Dec 2014 17:57:00 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 24 Dec 2014 20:57:00 -0500
Message-ID: <>
From: Watson Ladd <>
To: Michael Clark <>
Content-Type: text/plain; charset="UTF-8"
Cc: "<>" <>
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: Thu, 25 Dec 2014 01:57:03 -0000

On Wed, Dec 24, 2014 at 8:01 PM, Michael Clark <> wrote:
> Hi Peter,
> Someone pointed out RFC 7366 to me off list. I will read. I like the
> idea of encrypt-then-MAC being a core requirement for TLSv1.3.

And we have already made AEAD modes a requirement in the TLS 1.3
draft. I don't see the argument for adding RFC 7366 in addition to
> Before I've read through can we do this with it?
> AES-256-GCM + hmac_null   = 128 bits authentication
> AES-256-CBC + hmac_sha128 = 128 bits authentication
> AES-256-GCM + hmac_sha128 = 256 bits authentication
> AES-256-CBC + hmac_sha256 = 256 bits authentication
> AES-256-GCM + hmac_sha256 = 384 bits authentication
> AES-256-CBC + hmac_sha384 = 384 bits authentication
> I like the idea of >= 256 bits authentication, and the idea of the
> combination of a cipher based MAC and PRF based MAC for AES-GCM, given
> the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128).

I don't agree with this analysis.

For starters, GCM is not a PRF based authenticator. The security of
GCM authentication decreases with the length of the message, while the
security of HMAC authentication does not, while the numbers above
don't recognize this.

Secondly, attacks on authentication have to be online, and a failed
guess results in connection teardown. An attacker with a 2^{-64}
probability of forgery on any given connection would take decades to
inject data into a TLS connection, even if the connection restarted 1
million times a second.  By contrast, recovering data from a key 64
bits in length is a rather easy computation today, and will be easier

Thirdly, the weak keys of GCM are a red herring. Using the logic of
those papers, every GCM key is weak, as there is a known difference
between messages that will lead to a forgery if a given key is used.
One could make the same argument against CBC-MAC: if an attacker knows
the key, they can produce forgeries.

Fourthly, this ignores performance. Recent Intel chips have a
significant amount of acceleration for AES-GCM that cannot be used for
other modes. The parallelism of CTR mode permits hiding the latency of
the AES instructions, while the carryless multiply can't accelerate
HMAC. It also ignores implementation complexity: making two passes
over the data, with different algorithms, is more complex than one.

In short, there are no real security gains from this proposal. But
there are large losses in simplicity and performance, as now the
existing record layer transformations have to be redesigned and
stacked in ways they aren't currently. One can't say "such and such an
algorithm has more bits, therefore it is more secure". You have to
look at the exact claims, and see how they apply to the way the
algorithms are used.

Watson Ladd

> Michael.
> 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?
>> Peter.
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin