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

Yevgeniy Dodis <> Fri, 08 May 2020 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00E773A0F93; Fri, 8 May 2020 14:53:11 -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, 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 dm1svZl30K7u; Fri, 8 May 2020 14:53:08 -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 9F7F43A0F89; Fri, 8 May 2020 14:53:08 -0700 (PDT)
Received: by with SMTP id f82so2795034ilh.8; Fri, 08 May 2020 14:53:08 -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:content-transfer-encoding; bh=WKJ/rN42/jMsTkemOV1et9WP8g5q8g7xGv7iTWIBmsw=; b=Edil32QUhet4QnbfDY7/kO6X06XK8Y9bBVJc/zL2HuLJ3KA9Dm/sgHY4lCgyxK0uXa wc38a13KqRPkZcN72u/ur/h01cYFu47UrDUB5l7p0K4LTV4eY16v0DNeJyjdjGwIg0bo r6Jvk8fP75ynAwUsSfiw0Gax4y2kMUDZ9uCMowemtmKy/sXyiAvFD8P9i2UQOklKfhvi RpO5B+7Jd/UV1pKhAdJSKX9hE73wXRwYc9DV/n7k32iApRx73mDTu5s0QngcB36PMyBE s6X4RJnYfVPcpvVaAboQDKq5dOI22qs8XzLJWnwaO/JobUGqbgHjmEMExV2vHGWsAm5t 7JpA==
X-Gm-Message-State: AGi0PuYq+q85X7EGIphO49YBMMYq+VKyOaCHCdtO1vNxTrH7JSKcOcnk eOvBWGxAryDAaed/GqmhTer252GU6McHaLXJjWU=
X-Google-Smtp-Source: APiQypIY2rR+ZEw8kpc7O7gdSpVvoERO6f30Q3fTgRI2TI4GRSa8/k95Gw++fpa7n7GiDujpukzkK2NVkaxPYRDGLdI=
X-Received: by 2002:a92:c690:: with SMTP id o16mr4877909ilg.124.1588974787665; Fri, 08 May 2020 14:53:07 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Yevgeniy Dodis <>
Date: Fri, 08 May 2020 17:52:56 -0400
Message-ID: <>
To: "Salz, Rich" <>
Cc: "" <>, "" <>, Harish Karthikeyan <>, Sandro Coretti <>, Stefano Tessaro <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 08 May 2020 21:53:11 -0000

Dear all.

I just now noticed the call for comment for SP-800-56c. Please note
the state-of-the-art paper
on seedless randomness extraction in the recent CRYPTO'19 paper by
Sandro Coretti, Harish Karthikeyan, Stefano Tessaro and myself:
"Seedless Fruit is the Sweetest: Random Number Generation, Revisited",

Along its results, it strongly advises AGAINST using CBC-mode, such as
randomness extraction. It also gives very clean randomness extraction
modules based on
existing functions, such as SHA2 and SHA3, and also analyzes HKDF.

I (and likely my co-authors, cc'ed) will be happy to work with NIST on
making sure they follow state-of-the-art recommendation validated by
the top conferences such as CRYPTO. I admit I did not read the
document in detail, but it looks like it does not include any of the
optimized constructions from our paper, but still includes (at least
theoretically) insecure CMAC mode.

Can somebody recommend a proper course of action if my suspicion is correct?


On Fri, May 8, 2020 at 4:21 PM Salz, Rich
<> wrote:
> If you don’t care about FIPS-140, just delete this message, and avoid the temptation to argue how bad it is.
> NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-Establishment Schemes) is currently a draft in review. The document is at  Email comments can be sent to with a deadline of May 15.  That is not a lot of time.  The NIST crypto group is currently unlikely to include HKDF, which means that TLS 1.3 would not be part of FIPS. The CMVP folks at NIST understand this, and agree that this would be bad; they are looking at adding it, perhaps via an Implementation Guidance update.
> If you have a view of HKDF (and perhaps TLS 1.3), I strongly encourage you to comment at the above address.  Please do not comment here. I know that many members of industry and academia have been involved with TLS 1.3, and performed security analysis of it. If you are one of those people, *please* send email and ask the NIST Crypto Team to reconsider.
> Thank you.
>         /r$
> _______________________________________________
> Cfrg mailing list