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

"Paterson, Kenny" <> Tue, 13 January 2015 17:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C64C81A8BB2 for <>; Tue, 13 Jan 2015 09:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CCBBnGJyIQkC for <>; Tue, 13 Jan 2015 09:53:06 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe00::612]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA29D1A9029 for <>; Tue, 13 Jan 2015 09:53:05 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 13 Jan 2015 17:52:41 +0000
Received: from ([]) by ([]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 17:52:41 +0000
From: "Paterson, Kenny" <>
To: Manuel Pégourié-Gonnard <>, Peter Gutmann <>, "<>" <>
Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
Thread-Index: AdApm1DpFjNg+4muRmKsYOSI8dViWQAASE0AAWzH8IAAAojMgA==
Date: Tue, 13 Jan 2015 17:52:41 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
authentication-results: spf=none (sender IP is );
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR03MB381;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381;
x-forefront-prvs: 045584D28C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(479174004)(51704005)(243025005)(199003)(24454002)(83506001)(77156002)(54356999)(66066001)(105586002)(106356001)(40100003)(62966003)(19580395003)(19580405001)(50986999)(107886001)(76176999)(2900100001)(2656002)(102836002)(122556002)(15975445007)(68736005)(2950100001)(97736003)(87936001)(74482002)(36756003)(64706001)(46102003)(101416001)(77096005)(86362001)(92566002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 17:52:41.6443 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381
Archived-At: <>
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 17:53:09 -0000


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

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?



[1] RFC 5246, Section