Re: [Cfrg] draft-irtf-cfrg-kdf-uses-00

[Zooko Wilcox-O'Hearn <[e-mail]>]

Folks:

Just for your information, in the Tahoe-LAFS project we've decided  
not to use HKDF after all for our key-derivation needs.

We do not need extraction, only expansion—all of the seeds (or  
"master keys") that we input to a KDF are unguessable, evenly  
distributed values of exactly the appropriate size.

Therefore, we now intend to use a KDF which we think is simple,  
widely understood, efficient, and with a nice security reduction  
argument. Our proposed KDF is: let the resulting key be the first few  
bytes of the XSalsa20 keystream keyed by the master key.

If this KDF is distinguishable from random then this immediately  
implies a significant weakness in XSalsa20 as a cipher. XSalsa20  
exhibiting such a weakness would be very surprising.

We can use test vectors from other people's XSalsa20 implementations  
to check the correctness of our KDF in our unit tests.

Currently we are working on the next problem—which is out-of-scope of  
HKDF standardization—of how to securely, efficiently, and testably  
generate an integer of the appropriate range to use as the private  
exponent in elliptic curve DSA. You can see our notes about how to do  
that here:

http://allmydata.org/trac/pycryptopp/ticket/2#comment:13

Thank you very much to everyone, especially Dave McGrew and Hugo  
Krawcyck for patiently answering my questions about HKDF.

Regards,

Zooko Wilcox-O'Hearn
---
Your cloud storage provider does not need access to your data.
Tahoe-LAFS -- http://allmydata.org