Re: [Cfrg] existing KDFs and their uses

["Blumenthal, Uri" <uri at ll.mit.edu>]

So having this many different KDF's - why do we need one more, and how is it more secure (and more "random") than those already standardized??? 


----- Original Message -----
From: cfrg-bounces at irtf.org <cfrg-bounces at irtf.org>
To: Peter Gutmann <pgut001 at cs.auckland.ac.nz>; Dan Brown <dbrown at certicom.com>; David Jacobson <dmjacobson at sbcglobal.net>
Cc: Pasi.Eronen at nokia.com Eronen <Pasi.Eronen at nokia.com>; cfrg at irtf.org <cfrg at irtf.org>; Hugo Krawczyk <hugo at ee.technion.ac.il>
Sent: Wed Oct 21 11:29:06 2009
Subject: [Cfrg] existing KDFs and their uses

Hi Peter, Dan, and David,

> "Dan Brown" <dbrown at certicom.com> writes:
>
>> 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,
>

Peter Gutmann wrote:
> You missed out the SSH one, and what S/MIME uses for its DH keying,  
> and there
> are probably several others as well used in lesser-known protocols.   
> In fact
> every protocol that I know of has invented its own KDF, incompatible  
> with
> every other KDF out there, thus my question about why we need yet  
> another one.

David Jacobson wrote:
> NIST SP 800-90, which is actually about random number generation,  
> specifies two extractors, which it calls Derivation Functions, in  
> Section 10.4.1 and 10.4.2. These are hash based and block cipher  
> based, respectively.  Both can deal with generating internal key  
> material wider than a single block.  (I write "internal key  
> material" because the data so generated is used to as input to the  
> expansion function.)

good points, and it looks like underestimated the number of KDFs used  
to extract keys from DH in my note yesterday.   It would be valuable  
to list and categorize all of these functions and their uses, to  
better understand the situation.  Collecting text from all of our  
emails, here is a start:
Uses:
  1. Generate one key from another. In this case, no extraction stage  
is needed.
  2. Generate a key from a DH shared secret.  In this case,  
computational extraction seems to be needed, because statistical  
extraction would be inefficient.

  3. Generate key material from a non-uniform random source.  In this  
case, either statistical or computational extraction could be used.

   4. Generate a key from a passphrase.

KDFs:
P_SHA256 from Section 5 of RFC 5246, The Transport Layer Security  
(TLS) Protocol, Version 1.2.  (HMAC in an OFB mode variant)   Uses #1  
and #2.
P_MD5 XOR P_SHA1 from Section 5 of RFC 4346, The Transport Layer  
Security (TLS) Protocol Version 1.1.  (HMAC in an OFB mode variant,  
XORed with MD5 in the same mode.)  Uses #1 and #2.
AES-CMAC-PRF-128 from RFC 4615, The Advanced Encryption Standard- 
Cipher-based Message Authentication Code-Pseudo-Random Function-128  
(AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol  
(IKE).   Uses #1 and #2.

PRF+ from Section 2.13 of RFC 4306, IKEv2.   (HMAC in counter mode.)   
Uses #1 and #2.

SSH-KDF, Section 7.2 of RFC4253, The Secure Shell (SSH) Transport  
Layer Protocol.  (Hash function in counter mode.)  Uses #1 and #2.

AES-CM-PRF, Section 4.3.3 of RFC3711, The Secure Real-time Transport  
Protocol.

S/MIME DH KDF.  Section 2.1.2 of RFC 2631.  (Hash function.)  (Is this  
really the most up-to-date reference for SMIME DH?)   Uses #1 and #2.
Krb5-KDF from RFC 4402 A Pseudo-Random Function (PRF) for the Kerberos  
V Generic Security Service Application Program Interface (GSS-API)  
Mechanism.  (Hash function in counter mode.)  Use #1.

PBKDF1 (Hash function in OFB mode.) PBKDF2 (HMAC iterated, with all of  
the iterates XORed together.) from RFC2898, PKCS #5: Password-Based  
Cryptography Specification Version 2.0.   Use #4.

IEEE KDF1 (Hash function.)   Uses #1 and #2.

IEEE KDF2 (Hash function in counter mode.)   Uses #1 and #2.

ANSI X9.42 (Hash function.)   Uses #1 and #2.

ANSI X9.63 (Hash function in counter mode.)   Uses #1 and #2.

NIST SP 800-56A Concatenation-KDF and ASN.1-KDF (Hash function in  
counter mode.)   Uses #1 and #2.

NIST SP 800-90, Section 10.4 defines two extractors (hash function in  
counter mode, and a block cipher mode) and Sections 10.1, 10.2, and  
10.3 define some "expanders".   Use #3.

Additions and corrections are welcome.  Also, pointers to security  
analyses would be good to have, wherever they exist.
For each of these functions, it would be good to know a) under what  
conditions is it secure (e.g. what has to be assumed of the hash  
function) b) where and how is it used, c) does the protocol using it  
admit the replacement of its KDF, and if so, d) what is its interface  
(does it take a "salt" input, for example).
David