4 ms·
No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. Trying to make one that does both leads to some
by ori_b 11y ago
No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another.
Trying to make one that does both leads to something that sucks at both.
- laumars 11y ago> No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. That's not true either. Hashes are recommended to be used as input to KDFs. "Modern password-based key derivation functions, such as PBKDF2 (specified in RFC 2898), use a cryptographic hash, such as SHA-2" Source: https://en.wikipedia.org/wiki/Key_derivation_function#Key_stretching https://en.wikipedia.org/wiki/Key_derivation_function#Key_st... > Trying to make one that does both leads to something that sucks at both. eh? Nobody is advocating that what-so-ever. Not me, not anybody. I think you're now arguing with me for the sake of arguing with me. :-/
- ori_b 11y agoOk, that was sloppy phrasing on my part, but my point still stands: The entire reason that KDFs exist is to deal with the fact that hash functions are designed to be as fast as possible. If it made sense to make hash functions slow, then KDFs would not be needed. While KDFs do use hash functions internally, the hash function is an implementation detail.
- laumars 11y agoOk, thank you. That does make more sense now :)
- brohee 11y agoThe hilarious part here is Wikipedia calling PBKDF2 modern. It's a 2000 minimal update (to generate more bits, to be kind of UTF-8 aware) of a 1993 standard. At the time of the RFC publication it was already obvious its security was way behind bcrypt that was used in OpenBSD since 2.1 (June 1997), which did its best to be ASIC hostile, which isn't the case for PBKDF2. In retrospect, NIST choosing PBKDF2 over bcrypt in NIST SP800-132 could be seen as part of the effort to weaken standards for NSA profit.
- alextgordon 11y agoIronically this whole thread played out in the opposite direction at the time of SHA3's announcement: https://www.schneier.com/blog/archives/2012/10/keccak_is_sha-3.html https://www.schneier.com/blog/archives/2012/10/keccak_is_sha... https://www.imperialviolet.org/2012/10/21/nist.html https://www.imperialviolet.org/2012/10/21/nist.html tl;dr: Keccak is not a good partner for PBKDF2. It has good hardware performance but comparatively poor software performance. This benefits attackers with FPGAs or better.