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

["Dan Harkins" <[e-mail]>]

  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.

On Mon, November 26, 2007 10:46 am, [e-mail] wrote:
> 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
> [e-mail]
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg
>



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