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

Robert Ransom <> Fri, 15 November 2013 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D4611E81C4 for <>; Fri, 15 Nov 2013 11:43:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xg3W178TIfmX for <>; Fri, 15 Nov 2013 11:43:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::236]) by (Postfix) with ESMTP id 83F3D11E812F for <>; Fri, 15 Nov 2013 11:42:52 -0800 (PST)
Received: by with SMTP id j7so812593qaq.13 for <>; Fri, 15 Nov 2013 11:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Hr61sLhUaAXDCrlHHXMJCLH+rqcX7dkHEZGBVb7A0QU=; b=qBFJU4+SR62hba/mMFEvdrl9r0uay5VaTHmfzjxb5QHZo/4XuQWZz/2UgQ2392vi1o 9PNE2o0NWPrKpq1+uqrA/cm86EDTLlZlyDiR4Vkn2vABw/QXGVKAhAIAxRf9rMNgIx1s iSpUuT5lWaXpOtHfr2KEZgQdFRwPmCI1Zvqox5juUIIUZq9CCB9FmBiax7/3v/mHwLFI R3h5YJQTKDTtxlXbsrzRXxQ1GePFa0fTFUY5cHyOZ44Q8ujxBdP2mosWdkldktyy8i+m AKQqs5fwybQUlcJYql5KluOmCDtMW7q3wTC0y00RXdjBVgSmEYArixIP4d1JSviPhJ4t /bYQ==
MIME-Version: 1.0
X-Received: by with SMTP id p1mr13546191qcg.18.1384544571988; Fri, 15 Nov 2013 11:42:51 -0800 (PST)
Received: by with HTTP; Fri, 15 Nov 2013 11:42:51 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 15 Nov 2013 11:42:51 -0800
Message-ID: <>
From: Robert Ransom <>
To: Marsh Ray <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 19:43:19 -0000

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?

> Additionally, the concern (D) is raised that an attacker who completely
> succeeds with (C) may then be able to "reach back through" several
> additional layers of HMAC in the TLS PRF in order to derive one or both of
> the cipher keys allowing full decryption of the protocol stream.
> To be clear, I say "reach back through" because I don't think there is
> actually a name for this attack model. Even if we were just talking about a
> hash function instead of HMAC, this is an attack capability *beyond* primary
> preimage. Primary preimage is "given h(M), find M' such that h(M') = h(M)",
> whereas this attack is: "given h(M), find M"!

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

> The thing to worry about is block cipher modes' propensity to turn into
> plaintext oracles. This has been demonstrated as a practical attack on over
> and over again.

This is the most important point, and it's already being ignored (again).

> * Use encrypt-then-HMAC. Seriously. Yes really. No other choice is
> defensible in this age. If you think "oh but GCM" look more closely into its
> design.

There are plenty of other defensible choices for a MAC.

GCM has some bad design features, but its MAC is the good part (at
least for implementations with hardware support for multiplication in

Poly1305 (as used in draft-agl-chacha20-poly1305-03) is faster than
HMAC, and almost as secure.

SipHash is faster than Poly1305, and as secure as an HMAC truncated to
64 bits.  I don't expect it to be used in TLS, but it's certainly good
enough for voice communication protocols over UDP.

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.

Robert Ransom