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

Watson Ladd <> Tue, 13 January 2015 18:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 96FD01A902F for <>; Tue, 13 Jan 2015 10:09:51 -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 1HIi78FfeUt6 for <>; Tue, 13 Jan 2015 10:09:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DC541A904B for <>; Tue, 13 Jan 2015 10:09:42 -0800 (PST)
Received: by with SMTP id f73so2224535yha.6 for <>; Tue, 13 Jan 2015 10:09:41 -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:content-transfer-encoding; bh=ci1Sotqt/P1+WtIvyl0QVkVuhJ7+U4Pz7GSPCk42SFw=; b=tEnX6pf0vAlHAVhaV6MFmViJ9hEAUxJR47/yPloUGABDpl7TET96Cvhq8Fi7dN7cyT mNe4jcv2oVEhxsQuLdU2AKt+amlOBpp53G24+i9KK5h17NNTaYk1pnibZcOGlT8jjlb8 Y7afBd8XSQmftXKCD/loHiDZnShn9/l1yGhHACaVEPrw4fgnTw0iUksmBfNAq/JhYAs7 iGUiD7sFtRe3TjgCyZANmlPPgBB/D7QAZAOeFGrLvwYWBSZQ9HXeq8JnBbhfgy0lgIbC rsGcikxf9OaQXDQ/NJeVSEqL0Mj8N74XytC5x9+T3dRPDg/xDB/S3jpM1hWLhBg5frtL TDuA==
MIME-Version: 1.0
X-Received: by with SMTP id c69mr27250112yha.49.1421172581464; Tue, 13 Jan 2015 10:09:41 -0800 (PST)
Received: by with HTTP; Tue, 13 Jan 2015 10:09:41 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 13 Jan 2015 10:09:41 -0800
Message-ID: <>
From: Watson Ladd <>
To: "Paterson, Kenny" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: Manuel Pégourié-Gonnard <>, "<>" <>
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: Tue, 13 Jan 2015 18:09:51 -0000

On Tue, Jan 13, 2015 at 9:52 AM, Paterson, Kenny
<> wrote:
> Hi
> On 13/01/2015 16:39, "Manuel Pégourié-Gonnard" <> wrote:
>>On 06/01/2015 11:35, Paterson, Kenny wrote:
>>> It's good that nothing supports the truncated-MAC extension, because, in
>>> combination with TLS's support for variable length padding, it
>>> a security vulnerability. See:
>>> which shows that if the tag size (MAC length) is shorter than the
>>> block size, then there's a distinguishing attack that can tell the
>>> difference between the encryption of a short message and a longer
>>> (even though both are padded to the same size before encryption).
>>But if one does not expect any length hiding, is there still a problem
>>truncated MACs?
> I think one would expect length hiding at least up to the granularity of
> the block size in TLS with CBC mode. (The RFC even suggests that more
> should be possible: "Lengths longer than necessary might be desirable to
> frustrate attacks on a protocol that are based on analysis of the lengths
> of exchanged messages." [1])
> As a special case of the general attack, consider a notional application
> using TLS that sends either the message "YES" or the message "NO". Suppose
> we negotiate truncated MACs, and the TLS Record Protocol implementation
> selects the amount of padding to add at random (from the set of possible
> padding lengths allowed under the TLS padding scheme).
> By truncating the ciphertext, doing some bit flipping, and reinjecting the
> modified ciphertext, an adversary can tell whether "YES" or "NO" was
> originally encrypted. (This assumes that the minimum amount of padding is
> NOT selected; this happens with probability roughly 15/16 under the above
> assumptions.)
> I'd consider that to be an attack in your "don't expect any length hiding"
> setting - after all, the difference in plaintext lengths is just 1 byte,
> which is well below the CBC-mode block size. Does that seem reasonable, or
> is it still outside your attack model?

>From what I understand, when AES-GCM is used there isn't any padding,
and the length of the encrypted record is equal to the unencrypted one
plus the tag, so this attack still works. So if we accept this attack
(and I think we should), then the way AEAD ciphers are used in TLS are
also insecure. I believe this attack got used to determine autofill
entries in the Google search bar via passive observation, but I've not
dug up the paper, so my memory may be wrong.

To fix this we need to add padding in TLS 1.3 and TLS 1.2 for AEAD modes.

Watson Ladd

> Cheers
> Kenny
> [1] RFC 5246, Section
> _______________________________________________
> TLS mailing list