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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97A4221E80F1 for <>; Thu, 14 Nov 2013 15:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, J_BACKHAIR_44=1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_46=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5JVQDzg4P-Dq for <>; Thu, 14 Nov 2013 15:07:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3D36121E809F for <>; Thu, 14 Nov 2013 15:07:16 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 14 Nov 2013 23:07:11 +0000
Received: from mail181-db9 (localhost []) by (Postfix) with ESMTP id 34F511C0271 for <>; Thu, 14 Nov 2013 23:07:11 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: PS-4(zzbb2dI98dI148cI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hz97hz1de098h8275bh1de097hz2dh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(52604005)(51704005)(479174003)(199002)(189002)(83072001)(4396001)(46102001)(74876001)(49866001)(47976001)(50986001)(51856001)(54316002)(47736001)(83506001)(76176001)(85306002)(79102001)(1511001)(53806001)(76482001)(81816001)(76796001)(87936001)(59766001)(77982001)(74706001)(69226001)(76786001)(2656002)(87266001)(31966008)(74662001)(54356001)(74482001)(47446002)(74502001)(77096001)(56776001)(56816003)(74366001)(66066001)(65816001)(80976001)(80022001)(81686001)(81342001)(63696002)(81542001)(83322001)(19580405001)(36756003)(19580395003); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277;; CLIP:; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail181-db9 (localhost.localdomain []) by mail181-db9 (MessageSwitch) id 1384470428869583_16196; Thu, 14 Nov 2013 23:07:08 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id CF6ED1E0168; Thu, 14 Nov 2013 23:07:08 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 14 Nov 2013 23:07:05 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 23:07:05 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 23:07:04 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 23:07:04 +0000
From: "Paterson, Kenny" <>
To: Marsh Ray <>, "" <>
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAEmDYA
Date: Thu, 14 Nov 2013 23:07:04 +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="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 14 Nov 2013 23:07:24 -0000

+1 to almost everything in this post.

Let's now move on to discussing the substantive issues, keeping in the
forefront of our minds Marsh's wonderful phrasing:

"We should always be vigilant and paranoid. But the key to being
*constructively paranoid* is to worry about the *right* thing."


On 14/11/2013 21:00, "Marsh Ray" <> wrote:

>Our knowledge of generic hashing constructions has evolved:
>Standard constructions
>Length extension attacks
>Joux multicollisions/²2nd preimages for less work²
>Chosen-Target Forced-Prefix (Nostradamus, RapidSSL, Flame)
>Sponge constructions
>Attacks against specific hashes (MD4, MD5, SHA-0, SHA-1, SHA-2) tend to
>unfold in sequence:
>Reduced round collisions demonstrated (depends on reduction)
>Absurdly impractical multicollision and/or collision weakness theorized
>Plausible multicollision and/or collision weakness theorized
>Full collision demonstrated
>CTFP demonstrated
>2nd preimage theorized
>2nd preimage attack demonstrated
>Primary preimage attacks demonstrated
>The last I heard:
>MD4 is at stage 6
>MD5 is at stage 5
>SHA-0 was withdrawn at stage 3 or 4
>SHA-1 is at stage 3
>SHA-2 is at stage 2
>Now let¹s talk about HMAC.
>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
> on the security of HMAC. For example, assuming the key is actually
>secret from the attacker, you generally don¹t need to worry about
>collision attacks. The resulting MAC value or tag can be truncated and
>yet it still retains min(secret key bits, tag bits)
> security.
>In TLS, the secret key is generated by the TLS PRF. The TLS PRF is one of
>the most conservative parts of the design of TLS. It itself uses HMAC
> IIRC, to produce one block of PRF output takes something like 4
>invocations of the underlying hash¹s block function. It functions much
>like a slow, conservative block cipher with 512+160 bits of key and
>secret plaintext input (512+1024 for SHA-2-384 and -512).
>So the concern (C) has been raised that an attacker who may know some
>plaintext, and sees one or more samples of ciphertext, and the
>non-truncated MAC tag around
> this ciphertext, may then be able to ³reach back through² the HMAC to
>obtain the MAC key. This would enable him to forge ciphertext, which
>would enable him to and flip various bits decrypted plaintext bits. (Of
>course the current design allows anyone to do
> this today it¹s just that the later MAC will detect it so it becomes a
>game of oracle testing).
>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²!
>In other words, the attacker doesn¹t get to control the message input.
>Such a feat has never been openly proposed in the literature (that I¹ve
>seen on hash
> functions), not even theorized, not even for MD4.
>But again, our scenario (C) is not the use of plain hash functions. We¹re
>talking about attacking the use of HMAC<Hfn>(k, msg) to recover the
>secret key bits
> of input. This is yet another step removed from ³unthinkable².
>In the case where that the secret key length is the same as the MAC
>length, there¹s even about a coin toss chance there will be two or more
>keys that yield
> the target hash MAC. When the MAC is truncated, there are exponentially
>But again, for the concern (D), we¹re talking about accomplishing (C) and
>then continuing on to attack the TLS PRF through several cascaded
>HMAC<Hfn>(k, msg)
> to recover the secret key bits of input. This is yet another step
>removed from ³unthinkable².
>My conclusion is that for any reasonable choice of hash function, the TLS
>PRF is noninvertible. To put this another way, if this feat were
>demonstrated even
> using the horribly broken MD5 it would be earth-shattering in its crypto
>impact. It is secure forever, unless there are seriously fundamental
>advances in complexity-theoretic cryptanalysis. And if that day comes,
>*it will be your fast ciphers that you¹ll
> worry about*. The TLS PRF is by far the slowest, most conservatively
>designed stream cipher in common use.
>I would never say something is ³impossible² in cryptanalysis. We should
>always be vigilant and paranoid. But the key to being *constructively
> is to worry about the *right* thing. The security of HMAC<modern
>hash>(secret k, message) is *not* the right to worry about.
>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.
>* Put TLS PRF and HMAC security way, way down if not last on the list of
>things likely to negatively affect security.
>For all future TLS cipher suites and TLS 1.3 in general is:
>* 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.
>* Use the NIST-specified truncation SHA-2-512/256 for the HMAC hash
>* Don¹t truncate the TLS record MAC in an attempt to protect the master
>secret (as in the Finished message). Even if such an attack were
>practical, the attacker
> sees many samples of the MAC any way.
>* Do truncate the TLS record MAC to 128 bits because anything more is an
>indefensible waste of bandwidth.
>* Don¹t panic.
>Thanks for reading this far. I¹m fallible. TIA for details, factual
>corrections, and flames. These are my own personal opinions and not
>necessarily those of
> my employer.