Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)

Phillip Hallam-Baker <> Tue, 12 May 2020 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C3653A078F; Tue, 12 May 2020 10:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qJKnYwTjiMRI; Tue, 12 May 2020 10:04:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EF563A0781; Tue, 12 May 2020 10:04:01 -0700 (PDT)
Received: by with SMTP id o24so18865002oic.0; Tue, 12 May 2020 10:04:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jY7MvDbZfZJX0uNBfmz3LyIl59u0xgGT6UAUZhu7Ph8=; b=t4hFMnTlH9T63rgmCb4BLnMVBR4wFSRx6c2KMNh92SCW8ju9jA0xu255KTWQn5vCkZ WjuEiM13zXs+YS/L0NMiF2t3yPT/T4BHpo8yt/HZXqktZdy00rBnrGXtA9PvImD0oWUL W9IeeNfK8XW4bZKbgfHhsQf/DzuDk7iWR1jFu3Ukej8aRhWxnFvwHuinf5C2AADJPujS wPZPNlQwC80qVjlbGI3/S6offzwjK7nsxou+j28pgbxYNDkXKA0deQP77bCSdc/9YbHV Iq2fiTXDX3ZWsG5091pxyhFba4gpk4uBx2xcVFVjW6mcXdvYamn2fjA7x4aXZViSCmx0 //pg==
X-Gm-Message-State: AGi0PuaEC+UVDTR6tNlvFaQgKH5W5CuCi/YO7sEgcQR6Aws3X97p4QSA eE143IwXos0giGLc4aJnxo0r1PYwL74GSzCQmKk=
X-Google-Smtp-Source: APiQypKlrUBdusONp4+XJLqUOdM69kY5qx7uyXEEuAo7xVBqkppMqp3ag8SQdaTKS4yxSXTE/rm0KIX2DwYdGmTch+s=
X-Received: by 2002:a54:4601:: with SMTP id p1mr22096183oip.173.1589303040284; Tue, 12 May 2020 10:04:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Tue, 12 May 2020 13:03:49 -0400
Message-ID: <>
To: Dan Brown <>
Cc: Hugo Krawczyk <>, "Dang, Quynh H. (Fed)" <>, "" <>, "" <>, "Salz, Rich" <>
Content-Type: multipart/alternative; boundary="000000000000281bc205a57673d2"
Archived-At: <>
Subject: Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2020 17:04:04 -0000

On Tue, May 12, 2020 at 12:31 PM Dan Brown <> wrote:

> Hi Hugo,
> Some curious molehill questions. Please take with a grain of salt.
> In short, does HKDF-Extract suffer from related-salt and repeated-IKM?
> To elaborate:
> Phillip raises a good point below about HMAC suffering from key-extension
> (by zero bytes).  You are right that this is not a MAC attack, the main
> intended use of HMAC, but now the scope of HMAC has expanded to non-MAC
> purposes.
> Surely HMAC has good PRF properties, so non-MAC applications make sense.
> For what little it’s worth, I had just presumed that HKDF always used HMAC
> with the a strong secret key, like a good PRF should.  (I failed to verify
> this, though.)
> But Phillip seems to want to use structured HMAC keys (i.e. not uniformly
> distributed keys), specifically the salts in HKDF-Extract, I presume.
> Under my presumption, this would not be best practice (using structure or
> related keys).
> So, I went to the HKDF RFC, basically expecting to find this clearly
> disallowed.  Re-reading the RFC, it was unclear to me what kind of salt was
> allowed. (The eprint might be clearer, but it is longer to find this
> needle.) Would it (dis)allow the structured salts Phillip described?

The HMAC RFC is from 1997. While we have revised the spec to add new digest
algorithms, we have never revised the security considerations.

I think we should take the opportunity to level up to our current best
practices rather than relying on the old. Back in 1997 we were still using
DES as the blockcipher but very few folk were talking about the fact that
we should be considering birthday attacks and limiting the amount of
cipherstream generated under a particular key. We do consider that type of
issue today.

The concern I have is not the number of keys generated from a given IKM or
PRK so much as the amount of data those keys are used to encrypt. If I have
a log file with 1 million entries of 120 bytes, am I worse off by
generating 1 million keys from the same IKM or by generating one key and
using different IVs? The second is closer to customary practice but only
because we are considering the KDF as being a completely separate thing
from the block cipher key schedule.

Since I cannot do a key agreement for every log entry, there will be
related keys or repeated keys. The question is which we prefer.

Another application of the same approach is to encrypt a live video stream
and its associated data frame by frame with the intention of retaining
random access, fast forward etc. capabilities. I cannot perform a key
exchange per frame. But I can do a KDF per frame. Regarding the salt input
to the KDF as being a substitute for the IV gives me the performance and
flexibility I need without increasing the amount of data per entry. I just
generate an IV along with my session key.

The whole point of this approach is to construct a mechanism that allows me
to be very sure that every piece of encrypted data is encrypted under a
different key. It is really hard to screw up without it being apparent.

So in summary:

* Consider the NIST certification process to be an opportunity, not a

* We should revise the RFCs for HMAC and KDF. HMAC in particular needs
proper security considerations.

* We should look at the security of both the individual components and the
composition of the components in a system and require that both be sound as
opposed to allowing either.

* We should propose a simple, backwards compatible means of protecting
against the zero key padding issue on HMAC. One approach is simply
appending a non zero byte to the key. 0x50 is what I plan to use for my
HMAC variant unless someone has a better idea.