Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:

Marsh Ray <> Tue, 19 November 2013 05:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 909EF1AED90 for <>; Mon, 18 Nov 2013 21:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h4YuADhI7G3L for <>; Mon, 18 Nov 2013 21:15:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7FB8F1AED85 for <>; Mon, 18 Nov 2013 21:15:23 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 05:15:15 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 05:15:15 +0000
From: Marsh Ray <>
To: Bodo Moeller <>
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAvwiuAAANTVBAAjidLAAALI2vg
Date: Tue, 19 Nov 2013 05:15:14 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(199002)(189002)(51704005)(243025003)(83072001)(69226001)(76576001)(15975445006)(15202345003)(63696002)(76786001)(33646001)(77982001)(76796001)(74876001)(74706001)(74366001)(56816003)(54316002)(81816001)(56776001)(77096001)(19300405004)(85306002)(74316001)(59766001)(19580395003)(81686001)(81342001)(50986001)(47976001)(2656002)(74662001)(49866001)(47736001)(81542001)(65816001)(83322001)(80022001)(31966008)(87266001)(4396001)(47446002)(80976001)(74502001)(79102001)(66066001)(87936001)(54356001)(53806001)(51856001)(76482001)(46102001)(24736002)(562404015); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB076;; CLIP:; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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, 19 Nov 2013 05:15:26 -0000

From: Bodo Moeller
> While you are right, alone
> isn't why MtE is broken (and
> thus is a gross over-simplification -- not that there's anything
> wrong with that, per se ...).

Gross over-simplification tends to be what Twitter's best at.

AES-GCM good! RC4 bad! :-)

> That Bellare/Namprempre paper did show that MtE is not
> *generically* secure.  However, there's also
> =
> , showing
> (sort of) that MtE *is* secure if E specifically is, for example,
> CBC encryption.  Well, we all know how well *that* went [*][**]
> ... but the various problems with CBC ciphersuites are not implied
> by the Bellare/Namprempre paper.

I feel the world of end users, admins, and other RPs shaking their
collective heads in wonder at these security proofs when they see
a giant flame-shooting robot at a party in Argentina:

... then the presenter proceeds to decrypt traffic to a tier 1
ecommerce website ...

... and steal the login session cookie using attacks enabled
by CBC A-t-E mode.

All I can figure is that proving A-[at]-E CBC modes are
secure is cryptographers' equivalent of what (Down South where
I come from) we refer to as "Hey Y'all watch this!" E.g.,

We have a long, sad, bibliography of *practical* attacks on A-[at]-E,
especially in conjunction with CBC modes. Bellovin, Rogaway, Wei
Dei, Vaudenay (many I missed) . IPsec, SSH, SSL, TLS .
all broken to various degrees. Too many operations where
attacker-supplied data interacts with must-be-kept-secret data.
Straightforward implementations result in side channels. Minor
info leaks turn into oracles. Oracles turn into practical attacks.

Has there ever been a serious attack on HMAC<hashfn> ?

Here's what I found for HMAC<MD4>

Practical Electromagnetic Template Attack on HMAC
by Pierre-alain Fouque, Gaëtan Leurent, Denis Réal, Frédéric Valette
> In this paper, we show a very efficient side channel attack against
> HMAC. Our attack assumes the presence of a side channel that
> reveals the Hamming distance of some registers

But wait, HMAC<MD4> is worse. Again, *MD4*. IIRC TLS has only
ever supported HMAC<MD5> and later.

Full Key-Recovery Attacks on. HMAC/NMAC-MD4 and NMAC-MD5.
Pierre-Alain Fouque, Gaëtan Leurent, Phong Q. Nguyen.

So if, say, TLS had supported HMAC<MD4> and the adversary had
the ability to make 2^88 record integrity queries, then with
2^95 time he could possibly (in 2007) insert a forged record
in that connection. But he'd better be careful, because if
he breaks it he'll have to start all over.

This technique seems unlikely to be of any use attacking the TLS PRF
"back through" the record MAC, because the PRF operates upon
completely new data with every handshake.

But it looks like SSLv2 used a bare hash rather than HMAC and even had
an option for MD2! Still, it would likely have been the 512 bit RSA certs
that were the weakest link.


- Marsh

Unless stated otherwise, these are my own personal opinions.