Hugo Krawczyk <> Tue, 24 March 2015 17:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B62721AC3CF for <>; Tue, 24 Mar 2015 10:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CER2owxFuSwW for <>; Tue, 24 Mar 2015 10:29:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 380CA1A923B for <>; Tue, 24 Mar 2015 10:29:48 -0700 (PDT)
Received: by lbcgn8 with SMTP id gn8so145992878lbc.2 for <>; Tue, 24 Mar 2015 10:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cfpaOcFh7o4LVkYGfnE2HC6GkE+Ip7mtWaNsoAtLJuo=; b=zdZMczlMM2Dq9iApxDD+/nfXdGHz/bUFvqCPVpdLGxOZGHS7ZwVsWqWPih7mY+uqMa IG1N/BhT21fgMMD4j0YRpiq5h/xJmKYIEGPi0L49DSjrrk4gjC4t3mvUxLfSL7G5VTzg c9jSPzHq2BnvYEtCRXTGbIDvg8jJYXHYgWagb5YyOvjjsb95Krbdu3NX+jv52szrKgdv oWAtGaI+YRT6CgZIIbzJnnVj2uRQzrGKnQwazlsAsU7N8OuhohTkcRkTV3sSZVKFYFh6 HIioJuGlIo2O61FIU/3o1JNWkYB0PP/j3d4gqdg2iWlTPYBfoKyvaIUicVoemSOnk3Mx kphg==
X-Received: by with SMTP id al4mr4801328lbc.42.1427218185635; Tue, 24 Mar 2015 10:29:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 24 Mar 2015 10:29:15 -0700 (PDT)
In-Reply-To: <20150324121632.GA28552@LK-Perkele-VII>
References: <> <> <> <> <20150324121632.GA28552@LK-Perkele-VII>
From: Hugo Krawczyk <>
Date: Tue, 24 Mar 2015 13:29:15 -0400
X-Google-Sender-Auth: BEbwnk9aPeHWZJ02_yadqXUvyHk
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="001a11c23686f8cbe305120c208a"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] HKDF
X-Mailman-Version: 2.1.15
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: Tue, 24 Mar 2015 17:29:51 -0000

​Here are some clarifications about HKDF that can help better understanding
rationale and use in (OP)TLS.

Note: all places where I say random it can (and sometimes should) be
replaced by
pseudo-random meaning indistinguishable from a uniform random string.

- HKDF is standardized by NIST (as an *approved* KDF mechanism) in
  where it is explicitly stated that HKDF complies with this standard:
  "IETF RFC 5869 [10] describes an instantiation of the above
  extraction-then-expansion key derivation procedure using HMAC for the
  extraction and expansion steps. For extensive rationale on the key
  through the extraction-then-expansion procedure specified in this
  Recommendation see [11]." For those interested, [11] appeared in Crypto
  and is here

- HKDF uses a two-step mechanism by which one first extracts randomness
from a
  possibly non-uniform secret input to create a uniformly random string
that is
  then used with a regular PRF to generate keying material. In (OP)TLS we
  the two steps as HKDF-Extract and HKDF-Expand. The rationale of the
  part is to concentrate the "secret entropy" of the input on a single
  cryptographic key (from which more keys can be derived).

- HKDF uses HMAC for both extract and expand but it could use, in
principle, any
  regular PRF (including those from NIST) for expansion. Extraction is
  since it is not a generic property of PRFs. The reason to use HMAC for it
  that the HMAC construction has properties that support the extraction
  functionality under reasonable cryptographic assumptions.

- Skipping the extraction property would require keying a PRF with a
  key in which case the usual properties of PRF cannot be guaranteed as
  properties assume a uniform random key. In TLS with RSA this was not a
  since the key transported under RSA was chosen as a random uniform string.
  When using a DH key or passphrase this is not the case.

- Beyond the important cryptographic reasons for the extraction step, this
  solves the problem of having to adapt the size of the secret input to
that of
  a length of the key in the PRF: for example, how do you key AES-256 with a
  point on a 512 elliptic curve? Even with a 256 curve you would require
  compression which you may or may not want to use (I hope this comment
does not
  open a discussion of EC point representations :-).

- The expansion function of HKDF is HMAC-based and is ESSENTIALLY THE SAME
as in
  previous TLS. It even has the same feedback mode that TLS uses to expand
a key
  (the exact inputs to the iterations changes a bit but nothing major).

- There is no need for ultimate performance in the key derivation in TLS.
  operations are relative minor compared to the algebraic operations.

- There is nothing that ties HKDF to OPTLS in a fundamental way other than
  supports the provability of the protocol, hence improving the confidence
  its design. In particular, it supports a clean hierarchical key
derivation for
  all the protocol modes.


On Tue, Mar 24, 2015 at 8:16 AM, Ilari Liusvaara <> wrote:

> On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote:
> >
> > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <>
> wrote:
> > >
> > > Please note that at least some of these can be FIPS 140 tested (in
> particular, TLS PRF). Suite B expects the use of these approved KDFs.
> > >
> > > While NIST is perhaps too prolific with these, I feel that we should
> look into standard KDFs. There are test vectors, verifications systems,
> existing implementations…
> >
> > If such a KDF is needed for Suite-B, then it makes sense for Suite-B
> ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.
> >
> > Why not include a different PRF in those suites that have
> non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever
> signature scheme CFRG are going to recommend?
> Or even special Suite B ciphersuites. I think there are only 2 of
> those.
> - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
> - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384
> The basic idea being: They who care can implement that.
> -Ilari
> _______________________________________________
> TLS mailing list