Re: [Cfrg] existing KDFs and their uses

[Simon Josefsson <simon at josefsson.org>]

"Blumenthal, Uri" <uri at ll.mit.edu> writes:

> 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??? 

That is a reasonable question.  So far I haven't seen any answer to why
there is any need to make HKDF applicable to the medium-entropy password
scenario.  If I missed any argument in the recent flurry of e-mails,
please remind me.

/Simon

>
> ----- 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