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

Phillip Hallam-Baker <> Mon, 11 May 2020 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 971953A0B41; Mon, 11 May 2020 10:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rtz3U7cYBdDD; Mon, 11 May 2020 10:16:28 -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 859D03A0B39; Mon, 11 May 2020 10:16:28 -0700 (PDT)
Received: by with SMTP id o7so15770788oif.2; Mon, 11 May 2020 10:16:28 -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=sK/z/eYf+nSBCjPwcJ2PnY0uOjAhUiZ/9V3JGPqr94Y=; b=MmO1Nwk5AYMvIhd3iURzLgoQohqQlpJ29yeJW4+5R5lXluGXTZcC5u8mnwPA0GD2Ik iJj2sZa43syhIsekx+CsHpy/QyYjYARdBQTZrSkfVl3OCMvi8BZbr6osFz0un/gJCOim b5Ja4XSimQ0KU8xY4mwXKdWBx7R+6eTxo5lGumfHxiKj9AwSJitpoeIZIy1Y1zCl6wYx izbv9hoRdYi9JnsyXMyc0Z9WM1s9x7O8F7+YqOZNLlXhMDvQLqP5rm0AtZ6MtDvVpRa1 VAH7wGx7pIqMzwedLVMDRdCd4LKys/JeNYslzRAIOSqR5sDwZe0Y/IiekXYmmYfefzEX ICMQ==
X-Gm-Message-State: AGi0Pua9N8+M9PK6SezNKjJLsV4QgaHKIevKWhLPRM0xMbXoHOW+pn4F wJ8EDhRaSBEMljPZ0c4UXHV1+6jRmS6mfZW48Qk=
X-Google-Smtp-Source: APiQypJKplWGIAcCftxKuappOisJOgiOVr+SdX5iBcPqGOPFoc+TJ7lzeWMlCuuSK25YED5lnjPHkQtbG7RHYHDcKLc=
X-Received: by 2002:aca:b6c2:: with SMTP id g185mr20985146oif.166.1589217387624; Mon, 11 May 2020 10:16:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Mon, 11 May 2020 13:16:16 -0400
Message-ID: <>
To: "Dang, Quynh H. (Fed)" <>
Cc: "Salz, Rich" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000dc486905a562817b"
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 17:16:40 -0000

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.

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

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.