SHA-3 in XOF mode can be used (and was expected to be used) as a KDF. XOF mode is part of the NIST SHA-3 standard.
SHA-3 is incredibly versatile. This obsession with speed is unfortunate. It's a great function. If you've ever implemented SHA-3, it becomes obvious that all of these modes are simple changes in parameters to the core Keccak function--basically either changing the number of rounds or changing the output window size. And many of these degrees of freedom of Keccak are standardized as part of the NIST SHA-3 standard.
Contrast that with the BLAKE family of hash functions, which all involve substantial changes to the core routine. It didn't have to turn out that way as the original BLAKE proposal was quite versatile, but the downside of being passed over for standardization is greater susceptibility to fragmentation.
Once the core SHA-3 routine begins to see hardware support all of this handwringing and bikeshedding will be forgotten. Choosing SHA-3 today is a solid choice and should be beyond reproach, whereas not choosing SHA-3 should require a substantial and continued defense.
Also, it should be pointed out that the excessive security parameters of the standardized hashing modes will likely be considered prescient once the era of quantum computers is firmly established.
That doesn't mean you wouldn't want to be able to brute-force it (in theory). If you're dealing with a data format where you can easily write garbage to a few bytes (e.g. executables) brute forcing would let you find a useful collision.
Of course a hash function that won a NIST competition a few years ago has nothing to fear from bruteforcing via a specialized CPU instruction :P
His point was that cryptographic hash functions can be designed to be both slow or fast for different purposes. Key derivation functions and password-hashing functions like bcrypt and PBKDF2 are designed to be slow to mitigate brute-force attempts. But general-purpose hash functions like SHA-3 are not designed to be slow; in fact, you'd rather they be fast, because they're designed to be used in e.g. MACs.
In general, cryptographic hash functions are designed to be computed quickly, and key derivation functions are a special subset with greater difficulty requirements designed to be computed slowly. Your comment conflated the two, hence the parent's response.
wahern|8 years ago
SHA-3 is incredibly versatile. This obsession with speed is unfortunate. It's a great function. If you've ever implemented SHA-3, it becomes obvious that all of these modes are simple changes in parameters to the core Keccak function--basically either changing the number of rounds or changing the output window size. And many of these degrees of freedom of Keccak are standardized as part of the NIST SHA-3 standard.
Contrast that with the BLAKE family of hash functions, which all involve substantial changes to the core routine. It didn't have to turn out that way as the original BLAKE proposal was quite versatile, but the downside of being passed over for standardization is greater susceptibility to fragmentation.
Once the core SHA-3 routine begins to see hardware support all of this handwringing and bikeshedding will be forgotten. Choosing SHA-3 today is a solid choice and should be beyond reproach, whereas not choosing SHA-3 should require a substantial and continued defense.
wahern|8 years ago
johncolanduoni|8 years ago
Of course a hash function that won a NIST competition a few years ago has nothing to fear from bruteforcing via a specialized CPU instruction :P
wwwv|8 years ago
SamUK96|8 years ago
I said it was a hasher function already?
dsacco|8 years ago
In general, cryptographic hash functions are designed to be computed quickly, and key derivation functions are a special subset with greater difficulty requirements designed to be computed slowly. Your comment conflated the two, hence the parent's response.