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

Hugo Krawczyk <> Mon, 11 May 2020 20:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9AAB3A0B7B; Mon, 11 May 2020 13:37:04 -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 sJo_MRqU2-92; Mon, 11 May 2020 13:37:02 -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 504C73A0D7C; Mon, 11 May 2020 13:36:54 -0700 (PDT)
Received: by with SMTP id x20so5531530ejb.11; Mon, 11 May 2020 13:36:54 -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=acPvnX3Jev0xbhTvow3PfRMMe5oUsnXaSQayII3HVoY=; b=kLAgJS68626rpLiwlhHN3Axu+Tavv1gB3GbXcjIx8aZ0Se07SqdDo4PjLG1lz5ws7f Ya4tcw7ppf0ivzrRqhoLgo+xHYpNw+OrCU1vLb3yF2a998lxm0VM42qgJnZYrkTyGouK SFiOcy5ILcHRwFUBWJ/RXZSwF7hPhc9NMcc1qH2edI/AKCXD/nLiEkSHXlnXGUHWfGSI cMuUJyWu7Muw0zZHOUDzzxL3DUc1TFUvLQRkfc4qodcGkz84+j9kY1qjwkEOlzKQPTvS skznpKCNcZiF10EWosgIWCPmqZ6WzF3nsp1QPY2lRpunSwv/0J4+rBaRzbwNRbz8Pp6l jPbA==
X-Gm-Message-State: AOAM531gdY0jUzhLL1Wht+yXZoEJVjfdC/I3sbgiwBw7raLsZSc0fyBH uRrGVFpuOxqmKD4+odRCq/BU1wDh09LHrEm6hPM=
X-Google-Smtp-Source: ABdhPJy4VNXj2ODEgs3lTEboVx+Q1muuk439IMMniTMOWlpSLim0WhEuZo4Eqr+/cPp77NWwQjsP98zQ+oOO5HHD4eo=
X-Received: by 2002:a17:906:3cd:: with SMTP id c13mr81579eja.153.1589229412665; Mon, 11 May 2020 13:36:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Hugo Krawczyk <>
Date: Mon, 11 May 2020 16:36:24 -0400
Message-ID: <>
To: Phillip Hallam-Baker <>
Cc: "Dang, Quynh H. (Fed)" <>, "" <>, "" <>, "Salz, Rich" <>
Content-Type: multipart/alternative; boundary="0000000000009bcea805a5654e25"
Archived-At: <>
Subject: Re: [Cfrg] 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: Mon, 11 May 2020 20:37:05 -0000

There is no flaw if you use HMAC and HKDF as intended. See details below.

The bottom line advise is: If you are using related (not random) salt
values in HKDF, you are probably using it with  domain separation
functionality. In HKDF, domain separation is enforced via the info field
not the salt. Read the HKDF RFC and paper for background and rationale.

More below.

On Mon, May 11, 2020 at 1:19 PM Phillip Hallam-Baker <>

> I will forward this to the official comment address as well.
> I don't support making HKDF a NIST standard in its current form because
> there is a flaw.
> Consider the case in which the initial keying material is formed by
> concatenating two items, the second of which is a variable length string.
> As currently specified, the values for o_key and i_key are the same for a
> key k and that same key with a zero byte concatenated. This might not seem
> like a big deal but the whole point of defining common building blocks for
> crypto is to eliminate all the bear traps we can.

I assume that by o_key and i_key you mean the key xor-ed with opad and
ipad, respectively. Is that right?
It is true that in HMAC, and then in HKDF, you do not distinguish between a
key K shorter than a block and the same key with appended 0s.
This is OK in HMAC because as a MAC or PRF you must use HMAC with random
keys for which the probability to have the above property (choosing two
keys of different lengths, one  being the prefix of the other) is virtually
For HKDF, this issue applies to the salt value. Salt values (read the RFC)
should either be random or set to the all-zero string. Hence no issue there.

You can read the HKDF paper for extensive rationale for these choices.

> The problem can be eliminated as follows:
> 1) Generate i_key by padding the key value with byte x before XORing with
> the i_mask
> 2) Generate o_key by padding the key value with byte y (y <> x) before
> XORing with the o_mask
> This ensures that the values of o_key and i_key will change if zeros are
> appended.

It will not solve the issue if one of the keys is of a block length
Historical anecdote: The original design of HMAC had the concatenation
scheme as you suggest, Adi Shamir suggested changing it to xoring method
that was eventually adopted (see the Acknowledgment section in the HMAC
1996 paper),
So you can see that thought was put into these issues.

> This would require us to issue a revised version of HKDF. But I think we
> should do just that. Crypto utility functions should be robust under all
> known forms of mistreatment. I am probably not the only person who has
> multiple salt inputs to a KDF. Fortunately my unit tests caught the issue.

You should not have multiple salt inputs if they are not independently
If you want to use them for "domain separation", use the info field.

> Cfrg mailing list