Subject: [Cfrg] Fwd: existing KDFs and their uses

From: David McGrew <[email-masked]>
Date: Tue, 27 Oct 2009 11:20:23 -0700

Forwarding Peter's message to the list, because the mailman system  
isn't processing his mails correctly.

Begin forwarded message:

> From: Peter Gutmann <[email-masked]>
> Date: October 27, 2009 8:42:55 AM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Cfrg] existing KDFs and their uses
>
> [This is a re-post of two earlier attempted posts combined into one,
> apparently my earlier attempts didn't get through to the list.  Bits  
> of this
> have been replied to via CC'd copies to other people on the list,  
> sorry about
> the confusion]
>
> David McGrew <[email-masked]> writes:
>
>> Uses:
>
> There's also a fifth use which I don't think is covered by any of  
> the other
> four, generate multiple sets of cryptovariables (keys, IVs, nonces  
> whatever)
> from a single block of something-or-other (key + nonce + other odds  
> and ends),
> which is what SSL/TLS and SSH do.
>
>> 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?)
>
> Yes.  X9.42 was chosen for political reasons over RSA, so the spec  
> stipulated
> MUST X9.42, MAY RSA.  Implementors everywhere interpreted it as MUST  
> RSA,
> SHOULD NOT X9.42, and after awhile the spec stopped trying to  
> pretend it was a
> MUST as well, and then was allowed to fade into obscurity.
>
>> PBKDF2 (HMAC iterated, with all of the iterates XORed together.) from
>> RFC2898, PKCS #5: Password-Based Cryptography Specification Version  
>> 2.0.
>> Use #4.
>
> It's really all of them, since an iterated KDF is also a standard  
> KDF when
> iterations = 1.
>
>> Additions and corrections are welcome.
>
> There's also the PKCS #12 PRF and the OpenPGP PRF.
>
> How obscure can the protocols get?  There's others I know of in  
> little-used or
> application-specific standards that probably don't carry much  
> weight, does
> anyone really care what (say) the CMP PRF looks like?
>
>> Also, pointers to security analyses would be good to have, wherever  
>> they
>> exist.
>
> Security analyses?  Do we do those?
>
> The only ones I know of are for PBKDF2 and HKDF, although I haven't  
> looked at
> every available document on PRFs.  For most that I've seen it's just  
> security
> by executive fiat.
>
> The rationale and analysis document for HKDF is providing a very  
> valuable
> service, something I've been waiting for for a *long* time, my "Crypto
> Gardening Guide" has listed this as its primary crypto-problem-in-  
> need-of-
> solving since early 2003.  It's really good to finally see this  
> discussed and
> analysed in depth.
>
>> I guess that I should be careful to distinguish between what a  
>> function is
>> designed for and what it is used for.  Is PBKDF2 used with anything  
>> other
>> than passwords as its "secret" input?
>
> Yes.  The "PB" part of its name is a bit misleading, it's meant as  
> an update
> to what then became "PNKDF1" (i.e. "hash it with MD5"), but it's  
> really a
> general-purpose impedance-matcher for cryptovariables.
>
>> If it is specified for use on the Internet, and is actually used,  
>> it's worth
>> cataloging.
>
> This could be a big task... so off the top of my head there's the  
> Unix DES
> crypt, OpenBSD's bcrypt ("A Future-Adaptable Password Scheme"),  
> FreeBSD's
> scrypt ("Stronger Key Derivation via Sequential Memory-Hard  
> Functions"), Poul-
> Henning Kamp's iterated MD5 password hashing, OpenSSH's MD5 password  
> hash, ...
> once you get down to this level it may be better to just say that  
> there's a
> large number of further ones, with maybe a few of the above as  
> examples,
> rather than trying to enumerate them all.
>
> Peter.