4 ms·
As long as we've got some smart people hanging around: where does HKDF[1] fit into this? More specifically, when would you use HKDF over scrypt? 1. http://epri
by SoftwareMaven 15y ago
As long as we've got some smart people hanging around: where does HKDF[1] fit into this? More specifically, when would you use HKDF over scrypt?
1. http://eprint.iacr.org/2010/264.pdf http://eprint.iacr.org/2010/264.pdf
- tptacek 15y agoThis makes PBKDFs very di fferent than the general-purpose KDFs studied here. In particular, while passwords can be modeled as a source of keying material, this source has too little entropy to meaningfully apply our extractor approach except when modeling the hash function as a random oracle. Also the slowing-down approach of PBKDFs is undesirable for non-password settings
- SoftwareMaven 15y agoBut, as mentioned by @cperciva elsewhere in this thread, generating a key and creating a password hash are nearly synonymous. Using HKDF for passwords would be silly, but the more interesting question is: when would you use scrypt for key derivation in a system? More to the point: what are the tradeoffs you'd consider in choosing one over the other? (Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as its actual key derivation function for file encryption and authentication. Why scrypt instead of something else (and I have faith that it's not "not invented here" syndrome)?
- tptacek 15y agoI'm quoting the actual paper.
- SoftwareMaven 15y agoI am aware. I did read it before I posted it.
- tptacek 15y agoSo you think maybe Hugo Krawczyk is mistaken? :) Short answer: I think scrypt is an advancement over the class of constructions HKDF belongs to. If you're picking nits about which function to use, use scrypt.