Re: [Cfrg] soliciting feedback on HKDF

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

Hi there.

We've been considering using HKDF in the Tahoe-LAFS project [1].   
Here are some our notes on the topic: [2, 3, 4, 5]

I have a few questions.

One is, which parts of the security arguments in the full paper  
depend on "any good MAC" and which parts depend specifically on  
HMAC?  The full paper nicely names and cites all the properties that  
its arguments are predicated on, but unfortunately it does not always  
mention whether those properties (are believed to) hold of HMAC  
specifically or of a larger class of algorithms.

Another question is: suppose we want to derive a key which is >= 1  
and < order of an ECDSA group.  Should we use HKDF for the smallest  
number of bytes that are enough, check whether it is < the group  
order, and then if not get more bytes?  Or should we get more bytes  
up to some integral multiple of the group order, divide by that  
integral multiple, and then check whether it is < group order?  Or what?

Another question is: suppose we're doing one of these algorithms  
above, and we want to "get some more bytes" from HKDF . Should we  
just read more bytes, or should we change the INFO field, for example  
changing it to "Try number 2", and then read the first few bytes from  
this new instance?

Another question is: suppose we're doing one of these algorithms, and  
we want to spend more CPU power during the initial key generation in  
order to spend less CPU power during subsequent re-generation of that  
key.  Then could we iteratively pick an IKM, check whether it would  
produce a fitting key (>= 1 and < group order) in a single try, and  
if not start over and pick a different random IKM?

Another question is: should we really include the "extract" step even  
when the IKM is (believed by us) to be high-quality strong crypto  
keys, or should we "optimize out" the extract step and just use the  
expand step in this case?

Thank you very much!

Regards,

Zooko Wilcox-O'Hearn

[1] http://allmydata.com
[2] http://allmydata.org/trac/pycryptopp/ticket/2
[3] http://allmydata.org/pipermail/tahoe-dev/2009-August/002598.html
[4] http://groups.google.com/group/cryptopp-users/msg/01a2620f684a70bd
[5] http://groups.google.com/group/cryptopp-users/browse_thread/ 
thread/f30427601a5884f6