Re: hash_hkdf() signature

Hi Scott, On Wed, Feb 8, 2017 at 5:22 AM, Scott Arciszewski <scott@paragonie.com> wrote: > > One such real-world use case: Defuse v1 used HKDF without a salt. > > https://github.com/defuse/php-encryption/blob/ > b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L157-L170 > https://github.com/defuse/php-encryption/blob/ > b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L358 > > In version 2, we included a 32-byte random salt for each encryption, which > was stored next to the AES-256-CTR nonce in the ciphertext. (Both the nonce > and HKDF-salt, as well as the version information header, are covered by > the HMAC of the ciphertext.) > > The end result: Instead of having to worry about birthday collisions after > you've seen 2^64 AES outputs (because 128-bit randomly generated nonce), > now you need 2^192 before you have a useful collision. > > Although the RFC itself says that salts are optional, the argument to make > them required in PHP's implementation has merit. The only downside is: If > you're integrating with an implementation that doesn't require salts, and > the application doesn't use salts, you're out of luck. Is that enough of a > downside to dismiss an argument for better security? Maybe. > There are applications that do not require salt. In this case, all users has to do is $salt = NULL to omit $salt. Current signature has $length as the first optional parameter which would be set to "0" in many cases if not most. i.e. Just deriving new key from strong $ikm would not be typical. Requiring "$salt = NULL" to omit salt would not hurt API use much compare to current signature that requires "$length = 0" for most cases, I suppose. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net