Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

"Paterson, Kenny" <> Thu, 14 November 2013 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D554A11E8112 for <>; Thu, 14 Nov 2013 15:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U+FqHERPhLFM for <>; Thu, 14 Nov 2013 15:24:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D54621F9E12 for <>; Thu, 14 Nov 2013 15:24:08 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 14 Nov 2013 23:24:08 +0000
Received: from mail60-ch1 (localhost []) by (Postfix) with ESMTP id 17B1A2E0470; Thu, 14 Nov 2013 23:24:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -6
X-BigFish: PS-6(zzbb2dI98dI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275bh8275dh1de097h186068h5eeeKz2dh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(479174003)(243025003)(24454002)(51704005)(81686001)(81342001)(74366001)(66066001)(65816001)(80022001)(80976001)(19580395003)(83322001)(19580405001)(36756003)(63696002)(81542001)(83506001)(76176001)(85306002)(74876001)(46102001)(15975445006)(4396001)(83072001)(51856001)(47736001)(54316002)(49866001)(47976001)(50986001)(31966008)(87266001)(56776001)(77096001)(56816003)(74662001)(54356001)(74482001)(47446002)(74502001)(76482001)(81816001)(79102001)(53806001)(77982001)(59766001)(69226001)(74706001)(2656002)(76786001)(15202345003)(76796001)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277;; CLIP:; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail60-ch1 (localhost.localdomain []) by mail60-ch1 (MessageSwitch) id 1384471445420811_17668; Thu, 14 Nov 2013 23:24:05 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id 627862C0270; Thu, 14 Nov 2013 23:24:05 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 14 Nov 2013 23:24:05 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 23:24:03 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 23:24:02 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 23:24:02 +0000
From: "Paterson, Kenny" <>
To: "" <>, Ralf Skyper Kaiser <>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Date: Thu, 14 Nov 2013 23:24:02 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-forefront-prvs: 0030839EEE
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-Mailman-Version: 2.1.12
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, 14 Nov 2013 23:24:13 -0000

On 14/11/2013 16:21, "Martin Rex" <> wrote:

>Ralf Skyper Kaiser wrote:
>> With EtA you need to trust the MAC. With AtE you need to trust the
>> _and_ the MAC.
>I believe you're confused.
>The MAC provides integrity protection, the Encryption provides
>confidentiality.  The quality of the MAC has exactly Zero impact
>on the confidentiality provided by the Encryption.

Unfortunately, you're completely wrong. The MAC is also necessary to
preserve confidentiality in the face of active attacks. It's a very common
misunderstanding amongst novice cryptographers to believe that there's a

	MAC <-> integrity
	Enc <-> confidentiality

If you need an example, consider the security history of IPsec's
encryption-only modes. (Am I allowed to mention IPsec on a TLS list? Well,
I just did.) 

These modes provide confidentiality against passive attackers, yes, but
they fail pretty spectacularly against active attackers. Bellovin was the
first to show that; the nadir for encryption-only IPsec came in my 2007
Oakland paper with Jean Paul Degabriele, full version here:

(Just read the abstract if you've forgotten the headline.)

And, as far as I know, there are no significant attacks when IPsec is
configured in encrypt-then-MAC configurations (e.g. ESP conf+auth or ESP
followed by AH). On the other hand, all the configurations of IPsec where
the MAC is applied before the encryption are broken. (Another
demonstration that MAC-then-encrypt is not a robust choice.)

>For EtA, the characteristics&quality of the Cipher do not affect
>(and therefore can not improve) the quality of the MAC scheme
>at all.

That's true but irrelevant, unless you don't trust your MAC algorithm. So
why do you not trust HMAC-SHA256? Can you point to any shred of evidence
that it is weak in some way? That it is likely to become weak? That its
extensive security analysis is wrong? Without back-up of this kind, your
argument is just hot air. See also Marsh Ray's recent post.

>For AtE, the characteristics&quality of the Cipher additionally
>strengthen the quality of the MAC scheme, so weaknesses in the MAC
>scheme do not immediately translate into a vulnerability.

That's true too, but should be accorded small weight in the argument given
the litany of attacks against MAC-then-encrypt constructions.

>Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
>that does not have cryptographic hash properties (2nd paragraph Page 10):
>  GHASH is a keyed hash function but not, on its own, a cryptographic
>  hash function. This Recommendation only approves GHASH for use within
>  the context of GCM.
>The use of GHASH without cryptographic protection would not be safe.

Also true. But guess what? In GCM, the GHASH MAC is computed on the
ciphertext! The GHASH output is then encrypted using a further invocation
of the block cipher. Where does this leave your argument in favour of