On Tue, Feb 7, 2017 at 2:35 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Nikita, Andrey and all, <snip> > Regards, > > P.S. I'll be more careful, but I become very sloppy mail reader sometimes. > I appreciate if you could let know via private email. Thank you! > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > Hi, Although there are HKDF usage without salt, many HKDF applications with PHP > require or are better with salt. e.g. Previous per-session encryption. > Developers > will develop better application if they consider how salt could be used. > Therefore, > salt is better to be required parameter and omit it only when salt cannot be used. > > --- 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. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>
