[tahoe-dev] What is the 100 year crypto KDF?

Zooko O'Whielacronx zookog at gmail.com
Thu Jun 10 17:26:10 UTC 2010


How about HKDF?

New internet standard:

http://tools.ietf.org/html/rfc5869

The underlying hash function could be SHA-256, Comb4P, or something else.

advantages of HKDF:

 * standard (as Jack says: this is an important advantage)
 * carefully analyzed (http://eprint.iacr.org/2010/264.pdf )
 * weaknesses in the underlying hash might not lead to weaknesses in the KDF

disadvantages of HKDF compared to XSalsa20:

 * seems complicated compared to the simple XSalsa20 scheme I had envisioned
 * includes support for use-cases that we don't need (such as where
the seed is not a good high-entropy bitstring but is instead a DH
shared secret or a passphrase or something)
 * I don't trust SHA-256 to be a long-term good hash function as much
as I trust XSalsa20 to be a long-term good stream cipher
 * HKDF requires more CPU cycles

The thing that changed my mind from preferring XSalsa20 to preferring HKDF:

 * At CONfidence 2010, Willem Pinckaers pointed out to me that hash
functions have always been designed and evaluated with the model of
the attacker partially or completely knowing or partially or
completely controlling the inputs, where ciphers have usually been
designed and evaluated assuming that the attacker has no knowledge or
influence on the key. It would seem nicer for our KDF to be resilient
in this way, such as if an attacker can know or influence a few of the
bits of the master key, it would be nice if this gives him little
knowledge or control over the generated keys.

Regards,

Zooko



More information about the tahoe-dev mailing list