[Cfrg] why HKDF? -- Re: existing KDFs and their uses

[Zooko Wilcox-O'Hearn <zooko at zooko.com>]

I'm speaking as a consumer of such standards rather than as a  
producer.  I have already invented my own KDF [1] because, as far as  
I know, the existing specs don't spell out how to generate a random  
key which isn't just a certain number of bytes or bits, but instead a  
random element from a group.  (Fortunately I haven't yet deployed  
this KDF that I invented so I am still free to change it.)

At this time I would probably prefer to use HKDF over the other KDF  
algorithms that I know of because the accompanying full paper [2]  
comes with much more thorough arguments about its theoretical  
security properties.  It isn't perfect for me!  As I mentioned in my  
initial questions, HKDF has the same omission that the others do in  
specifying how to generate keys which aren't just byte sequences, and  
it isn't entirely clear to me whether the security arguments for HKDF  
are predicated on the underlying primitive being HMAC, being a MAC,  
being a PRF, or what.  (I am more comfortable relying on AES or  
Salsa20 to be like an ideal cipher than relying on SHA-256 or SHA-512  
to be like an ideal hash function.)

Also I don't know which of those same security arguments apply to the  
other KDFs.

Also it isn't clear whether I should skip the extract step when my  
original key is already densely packed with nutritious entropy.

However, as things stand I would much rather use HKDF since it is  
apparent that someone (Hugo Krawczyck) has spent the effort to  
analyze and write down a bunch of relevant security arguments.   
HKDF's rigorous reductions (as far as I understand them) and its  
heuristic design both look good to me.

Regards,

Zooko

[1] http://allmydata.org/trac/pycryptopp/browser/pycryptopp/publickey/ 
ecdsamodule.cpp?rev=672#L269
[2] http://webee.technion.ac.il/~hugo/kdf/kdf.pdf