Subject: [Cfrg] Key Derivation Functions and Randomized Hashing from NIST

From: [email-masked]
Date: Mon, 26 Nov 2007 13:46:38 -0500

As many of you know, NIST has specified two standard KDFs for use with
key agreement algorithms (e.g., Diffie-Hellman or MQV) in NIST SP
800-56A. NIST is considering supplementing the 800-56A KDFs with a  
more broadly applicable KDF.  In particular, NIST is considering a proposal 
for an HMAC-based KDF.  Before committing resources to this effort, we would
like to get a better handle on the requirements seen by protocol  
developers and evaluate the level of support for such a standard.  We would 
also like to identify alternative designs that should be considered.

NIST also posted a draft publication of randomized hashing for public  
comment in July. This project was inspired by Shai Halevi and Hugo Krawczyk's
publication on randomized hashing, which can be found at
http://www.ee.technion.ac.il/~hugo/rhash/. The NIST draft is located at
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-106. The
randomization technique in this publication is slightly different  
from the technique designed by Shai Halevi and Hugo Krawczyk.  NIST is
currently seeking feedback with respect to the applicability of  
randomization techniques for IETF protocols, and the relative impediments to
implementation and deployment.

I will attend the IETF meeting in Vancouver Canada from the 2nd to  
the 7th of December 2007 and would like to take this opportunity to discuss  
the issues mentioned above with parties who have interest in these topics.

Quynh Dang
NIST
[email-masked]

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 27 Nov 2007 13:26:30 +1300

[email-masked] writes:

>In particular, NIST is considering a proposal for an HMAC-based KDF.  Before
>committing resources to this effort, we would like to get a better handle on
>the requirements seen by protocol developers and evaluate the level of
>support for such a standard.  We would also like to identify alternative
>designs that should be considered.

Uhh, hasn't PBKDF2 solved this problem for some years already?  That is, it
seems like the easiest solution would be to just adopt PBKDF2 wholesale.

Peter.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 27 Nov 2007 13:32:47 -0800 (PST)

Hi Quynh,

  Thank you for soliciting input on a new KDF. Let me provide some:

 1. Please consider a KDF which uses a PRF based on a symmetric cipher
    and not just an HMAC of a hash function. It is desirable to implement
    a secure system with a minimum of cryptographic primitives and the
    assumptions placed on them.

 2. Please consider speed. Sometimes a KDF is a one-off function performed
    after key agreement. But in some situations this is not realistic. For
    instance in a mesh network (e.g. IEEE 802.11s) environmental changes
    can cause links to go up and down repeatedly and session keys may need
    to be derived frequently from the shared secret. Also, various "fast
    roaming" schemes are being proposed in which a "master key" is used
    in a KDF to derive scores, and perhaps hundreds, of keys (e.g. the
    HOKEY WG in the IETF, or IEEE 802.11r).

 3. The KDF in 800-56A is KDF(Z, Otherinput) where Z is the secret, and
    Otherinput is the keydatalen and Otherdata. Otherdata is defined as
    at least 3 and possibly 5 distinct inputs all concatenated together.
    This is the way most people define KDFs: it takes a key, a keydatalen,
    and then a single input comprised of the concatenation of several
    distinct inputs. Please consider this as the degenerate case of a KDF
    with a KDF that can accept distinct inputs distinctly as the general
    case. In other words I'd like to see an interface like this:

       KDF(Z, keydatalen, data1, data2, data3, ....)

    instead of like this:

       KDF(Z, keydatalen, data1|data2|data3|...)

    Many times the data passed to the KDF is some context and/or a label
    to bind to the derived key. Often much of this is constant over many
    invocations of the KDF and there are efficiencies that can trivially
    gained with a KDF using the former input and not the later input. If
    the underlying PRF takes a single input then the data can be marshalled
    into a single input as it is today but the interface to the KDF should
    not preclude a PRF that handles its input naturally. Again, a single
    input should be supported as the degenerate case but not mandated as
    the general case.

 To answer your question about alternative designs I would like you to
consider S2V (from the paper "Deterministic Authenticated Encryption" by
Rogaway and Shrimpton). A KDF based on this was recently voted into the
IEEE 802.11s draft. The new 802.11s KDF uses S2V with AES-CMAC (number 1
above), it is approximately four times faster than the HMACSHA256-based
KDF it replaced (number 2 above), and accepts a vector of distinct inputs
(number 3 above).

  I look forward seeing you in Vancouver. And thanks again,

  Dan.