Subject: [Cfrg] soliciting feedback on HKDF

From: David McGrew <[email-masked]>
Date: Mon, 19 Oct 2009 10:45:15 -0700

Hello,

HMAC-based Extract-and-Expand Key Derivation Function (HKDF), http://tools.ietf.org/html/draft-krawczyk-hkdf-00 
, specifies a key derivation function that is intended to be used in a  
wide variety of applications.   This draft provides a detailed  
proposal along the lines of what Hugo presented to the IETF Security  
Area at IETF 74.   If you have an interest in the design and/or use of  
this KDF, please provide your feedback to the CFRG list.

It would be ideal to have feedback by November 8, so that it can be  
considered at the upcoming IETF meeting.  However, comments are  
welcome at any time.

David

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 19 Oct 2009 20:06:06 +0200

I believe this is a useful document, nice work!

There is one part which appears (intentionally) underspecified that I
fear may lead to a sub-optimal deployment scenario.  The document says:

4. Applications of HKDF
...
   One significant example is the derivation of cryptographic
   keys from a source of low entropy such as a user's password.
   ...
   Therefore, PBKDF
   applications interested in adapting HKDF to their setting can either
   replace the extract step with an intentional slow-down mechanism
   (e.g., applying repeated hashing) or can use both the extract and
   expand mechanism of HKDF with a slowing-down mechanism applied after
   the extract step and before expansion.

If implementers take this suggestion literally, there is a risk that we
will end up with more than one HKDF-derived password-based KDF with
slightly different properties.

We already have one standardized PBKDF: PKCS#5 PBKDF2 from RFC 2898.  It
is close in spirit to the HKDF.

Q: Does the PBKDF2 have some sub-optimal property that suggests we need
to consider replacements?

If there is not (I am not aware of any reason), I suggest the HKDF
document should recommend applications that are interested in a PBKDF to
look at RFC 2898 PBKDF2 rather than suggesting to invent something based
on HKDF.

The alternative would be to specify a "standard" password-based HKDF
function in the the HKDF document that also takes an iteration count to
burn some cycles.

Given that PKCS#5 PBKDF is already deployed in several protocols, I
believe we need a good rationale for introducing another PBKDF at this
point.

FWIW, understanding if there is any problem with the PBKDF2 would be
useful in the context of the upcoming SCRAM-SHA-1 SASL mechanism too.

Thanks,
/Simon

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 19 Oct 2009 16:36:44 -0700 (PDT)

Hello,

  A very nice I-D and I think HKDF will be a valuable building
block for protocol designers.

  First a (drawn-out) question:

  The HKDF-extract function uses HMAC-hash, a keyed pseudo-random
function (PRF) that represents a family of mappings, one for each
key, of (a double invocation of) "hash". HKDF uses an optional "salt"
as the key to this PRF. When the salt is not given a number of zeros
equal to the block size of "hash" is used. Also, a given "salt" can
be reused across multiple invocations of HKDF. Which means the PRF is
being reduced to a single mapping from its family of maps. So why use
the PRF construct of HMAC-hash for HKDF-extract()? Unless the "salt"
is mandatory and distinct (and possibly just unpredictable, not
necessarily random) for each invocation of HKDF I don't see the point.

  If there is a benefit to using HMAC-hash with a (possibly) fixed
key over just using "hash", it would be helpful to spell that out
somewhere in the draft. If not, I think it would be simpler to just
use a single function map if that's all that's needed.

  And now a suggestion:

  It would be nice to add to the security considerations a description
of the property that HKDF-extract() has that is useful for concentrating
the entropy of the input key. That would help when people start trying
to instantiate HKDF with different values of "hash". Or, to guide the
hands of people who might not really know what they're doing, consider
creating an IANA registry of specific instantiations of HKDF with
different values of "hash" and specify some kind of "expert review" to
add new values to the registry.

  regards,

  Dan.

On Mon, October 19, 2009 10:45 am, David McGrew wrote:
> Hello,
>
> HMAC-based Extract-and-Expand Key Derivation Function (HKDF),
> http://tools.ietf.org/html/draft-krawczyk-hkdf-00
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Zooko Wilcox-O'Hearn <[email-masked]>
Date: Mon, 19 Oct 2009 17:46:12 -0600

Hi there.

We've been considering using HKDF in the Tahoe-LAFS project [1].   
Here are some our notes on the topic: [2, 3, 4, 5]

I have a few questions.

One is, which parts of the security arguments in the full paper  
depend on "any good MAC" and which parts depend specifically on  
HMAC?  The full paper nicely names and cites all the properties that  
its arguments are predicated on, but unfortunately it does not always  
mention whether those properties (are believed to) hold of HMAC  
specifically or of a larger class of algorithms.

Another question is: suppose we want to derive a key which is >= 1  
and < order of an ECDSA group.  Should we use HKDF for the smallest  
number of bytes that are enough, check whether it is < the group  
order, and then if not get more bytes?  Or should we get more bytes  
up to some integral multiple of the group order, divide by that  
integral multiple, and then check whether it is < group order?  Or what?

Another question is: suppose we're doing one of these algorithms  
above, and we want to "get some more bytes" from HKDF . Should we  
just read more bytes, or should we change the INFO field, for example  
changing it to "Try number 2", and then read the first few bytes from  
this new instance?

Another question is: suppose we're doing one of these algorithms, and  
we want to spend more CPU power during the initial key generation in  
order to spend less CPU power during subsequent re-generation of that  
key.  Then could we iteratively pick an IKM, check whether it would  
produce a fitting key (>= 1 and < group order) in a single try, and  
if not start over and pick a different random IKM?

Another question is: should we really include the "extract" step even  
when the IKM is (believed by us) to be high-quality strong crypto  
keys, or should we "optimize out" the extract step and just use the  
expand step in this case?

Thank you very much!

Regards,

Zooko Wilcox-O'Hearn

[1] http://allmydata.com
[2] http://allmydata.org/trac/pycryptopp/ticket/2
[3] http://allmydata.org/pipermail/tahoe-dev/2009-August/002598.html
[4] http://groups.google.com/group/cryptopp-users/msg/01a2620f684a70bd
[5] http://groups.google.com/group/cryptopp-users/browse_thread/ 
thread/f30427601a5884f6

---

From: Zooko Wilcox-O'Hearn <[email-masked]>
Date: Mon, 19 Oct 2009 21:36:24 -0600

> block for protocol designers.

I would like to echo this sentiment: in attempting to stringently  
evaluate "Everything that could possibly go wrong" with Tahoe-LAFS's  
crypto design [1], I keep thinking that the KDF is a linchpin  
component in several places.  (The recent revelation of related-key  
issues in AES-256 is one of the reasons to think this.)  Thank you  
for working on the design and standardization of HKDF!

For what it is worth -- I really don't want to start an argument  
about this somewhat tangential issue -- I don't like HMAC-SHA256  
nearly as well as I like Poly1305-AES or Poly1305-Salsa20.  This is  
an unfortunate period in cryptography when there isn't a really good  
secure hash function that we can rely on, and the strong security  
proofs and superior performance of the Carter-Wegman MACs like  
Poly1305 look better to me than the security proofs of HMAC.

Regards,

Zooko Wilcox-O'Hearn

[1] http://allmydata.org/trac/tahoe/wiki/NewCaps/WhatCouldGoWrong

---

From: "Dan Brown" <[email-masked]>
Date: Tue, 20 Oct 2009 11:26:18 -0400

1. For key generation (not key derivation), I believe that NIST SP
800-90 is meant to be applied by most NIST standards, e.g. FIPS 186-3.
There is also the ANSI X9.83 standards, which has a part 3 aligning with
NIST SP 800-90, and a draft part 2 discussing entropy sources (their
assessment and perhaps debiasing), and a draft part 4 combining the
latter two (so part 4 overlaps in aim with the HKDF), and again other
ANSI crypto standards will expect X9.82 to be used for key generation.

2.  The menagerie of key derivation functions (i.e. DH-like shared
secret value to symmetric key, which unlike key generation are needed
for interoperability) such as IEEE KDF1 and KDF2, ANSI X9.63 X9.42, NIST
SP 800-56A, TLS-PRF, and IKE, and now HKDF, could lead a general purpose
crypto module to be application-limited, or to support multiple KDFs, or
to output the raw shared DH secret value (g^(xy)). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David McGrew
Sent: Monday, October 19, 2009 1:45 PM
To: [email-masked]
Cc: Tim Polk; [email-masked] Eronen; Hugo Krawczyk
Subject: [Cfrg] soliciting feedback on HKDF

Hello,

It would be ideal to have feedback by November 8, so that it can be
considered at the upcoming IETF meeting.  However, comments are welcome
at any time.

David

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.