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

"Paterson, Kenny" <> Tue, 03 December 2013 19:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 10CD91A8032 for <>; Tue, 3 Dec 2013 11:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R9-hPT6GCjCL for <>; Tue, 3 Dec 2013 11:12:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 19EF91ACCDE for <>; Tue, 3 Dec 2013 11:12:29 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server id; Tue, 3 Dec 2013 19:12:27 +0000
Received: from mail3-ch1 (localhost []) by (Postfix) with ESMTP id 21160E039F; Tue, 3 Dec 2013 19:12:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: PS-20(zzc89bh542I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(51704005)(81342001)(56776001)(15202345003)(74316001)(85306002)(54316002)(53806001)(19580405001)(74662001)(90146001)(56816005)(85852002)(76796001)(81686001)(76786001)(87266001)(74502001)(81542001)(54356001)(59766001)(79102001)(74366001)(77982001)(2656002)(83322001)(15975445006)(47736001)(49866001)(76576001)(50986001)(4396001)(74876001)(47446002)(83072001)(80976001)(33646001)(46102001)(19580395003)(81816001)(31966008)(51856001)(47976001)(76482001)(69226001)(74482001)(66066001)(74706001)(87936001)(63696002)(65816001)(80022001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB4PR03MB380;; CLIP:; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail3-ch1 (localhost.localdomain []) by mail3-ch1 (MessageSwitch) id 1386097944954624_22489; Tue, 3 Dec 2013 19:12:24 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id E3A6B3C00D2; Tue, 3 Dec 2013 19:12:24 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 3 Dec 2013 19:12:24 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 3 Dec 2013 19:12:23 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 3 Dec 2013 19:12:22 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Tue, 3 Dec 2013 19:12:21 +0000
From: "Paterson, Kenny" <>
To: "" <>, =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO7R77H2f5vAeCGkOkJhCJPGzqVZo8bsWAgAA2+ACABhAcAA==
Date: Tue, 3 Dec 2013 19:12:21 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0049B3F387
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>, Peter Gutmann <>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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, 03 Dec 2013 19:12:33 -0000

Hi Martin,

> -----Original Message-----
> From: Martin Rex
> Sent: 29 November 2013 20:17
> To: Juho Vähä-Herttua
> Cc: <>rg>; Peter Gutmann
> Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
> >
> > I'm sure you have good reasons for this opposition, so could you
> > please explain them in one or two sentences. This excluding the
> > "encrypting the HMAC makes it safer" argument, which might be true but
> > as I understand is not well proven.
> The fact that GHASH must be encrypted is sufficient proof that an encrypted
> MAC provides a better safety margin than a plaintext MAC.

You seem to be making the assumption that GHASH is a MAC algorithm. It's not.
It's a universal hash function, that is, a function designed so that a particular bound on the 
probability of collision holds when the hash key is chosen uniformly at random, quantified over
all possible pairs of input messages. See

for definitions.

GHASH is not itself intended to provide the unforgeability properties that we expect from a MAC.

In more detail, this kind of hash function can serve as the basis for building a MAC, but cannot be 
used alone for that purpose. A fairly standard construction that uses a universal hash function like 
GHASH to build a MAC is to mask the GHASH output using a pseudorandom value computed using 
a (second) secret key.  

In AES-GCM, the security proof allows this pseudorandom value to be generated using the
encryption key with counter mode of AES, which happens to be the same mode used for 
encryption of the plaintext. This is convenient for implementation, but not a necessary 
feature for building a MAC from a universal hash function.

So I don't believe it is either helpful or correct to cite GHASH as evidence that 
MAC-then-encrypt provides a better safety margin than a plaintext MAC.

> MAC in the clear is only safe when the MAC algorithm is sufficiently close to
> perfect.  We know painfully well that our hash algorithms are *not* perfect, so
> I'm against taking chances, in particular for the GenericBlockCipher PDU.

Here you first refer to MAC algorithms needing to be perfect, then hash algorithms 
not being perfect. But these are different things. And all the evidence from the cryptographic
literature suggests that attacks on hash functions do not tidily convert into attacks on MAC
algorithms built from these hash functions (I refer here to the significant body of research on this
topic, including but not limited to: Fouque et al at Crypto 2007, L. Wang et al. at Eurocrypt 2008, 
X. Wang et al. at Eurocrypt 2009, and more recent work, e.g. Peyrin et al. at Asiacrypt 2012).