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

Marsh Ray <> Fri, 15 November 2013 22:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7899711E815C for <>; Fri, 15 Nov 2013 14:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NM+L-+5itf0g for <>; Fri, 15 Nov 2013 14:44:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CD84411E8193 for <>; Fri, 15 Nov 2013 14:44:25 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Fri, 15 Nov 2013 22:44:21 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Fri, 15 Nov 2013 22:44:21 +0000
From: Marsh Ray <>
To: Robert Ransom <>
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAvwiuAAANTVBA=
Date: Fri, 15 Nov 2013 22:44:21 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(24454002)(199002)(189002)(51704005)(377454003)(76796001)(54356001)(74876001)(74706001)(76786001)(56816003)(79102001)(77982001)(76576001)(51856001)(69226001)(63696002)(77096001)(59766001)(85306002)(15202345003)(83072001)(53806001)(15975445006)(33646001)(76482001)(65816001)(47446002)(74502001)(19580395003)(50986001)(47976001)(87936001)(54316002)(81342001)(2656002)(31966008)(83322001)(19580405001)(80022001)(46102001)(74662001)(66066001)(56776001)(81686001)(81542001)(80976001)(4396001)(87266001)(47736001)(81816001)(74316001)(74366001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB074;; CLIP:; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Fri, 15 Nov 2013 22:44:30 -0000

From: Robert Ransom []
Sent: Friday, November 15, 2013 11:43 AM
> On 11/14/13, Marsh Ray <> wrote:
> > HMAC uses a double invocation of the full hash function each of which
> > is initialized with a secret key. There's some pretty well respected
> > proven properties on the security of HMAC.
> Are these properties proved for all iterative hash functions, or only for hash
> functions with the same general structure (block cipher in feedforward
> mode) as MD5 and the pre-SHA-3 NSA hash functions?

One would certainly hope the properties would still hold when used with actual hash functions which differ from an ideal hash function in a subset of ways.

ISTR one of the original NIST requirements for SHA-3 was that it be compatible with existing constructions like HMAC. On the other hand, NIST seemed to feel that some of the other original requirements were still negotiable (e.g., preimage resistance of two times collision resistance).

NIST suggests they will standardize a specific MAC mode for SHA-3. I haven't heard anything to suggest this provides any security advantage over HMAC, just a little more performance for short messages.

> I call that a “preimage recovery attack”.  I don't think that name is standard,
> but it is an accurate description of the attack.

Intuitively that makes sense as a descriptive term.

But I find for myself that having such an attractive term around is a dangerous temptation!

My search engine turns up only one hit for the term:

I think it's a reasonable question and the asker gets a good answer, but I would much rather see it defined a bit more formally. It probably has been somewhere.

> There are plenty of other defensible choices for a MAC.

Yeah, I didn't mean to imply so much that HMAC is the One True MAC or that integrated AE modes can never be defensible. Just that MAC-(then|and)-Encrypt are broken while Encrypt-then-HMAC is a very conservative design which has stood the test of time and emerged victorious.

Figure 2 from

> GCM has some bad design features, but its MAC is the good part (at least for
> implementations with hardware support for multiplication in GF(2)[X]).

What *doesn't* look good if we restrict our discussion to configurations which have explicit hardware support?

Wait...I'll answer that: RC4 :-)
> With a good hash function (one which does not permit the length-extension
> attack), such as any of the SHA-3 finalists, H(k, m) is a good MAC.

What if (as in the TLS handshake) m itself was used to negotiate the length of k?

- Marsh
Usual disclaimers apply.