Hi Nikita, On Mon, Jan 16, 2017 at 8:08 PM, Nikita Popov <nikita....@gmail.com> wrote:
> Making the salt required makes no sense to me. > It does not make sense to me too if API requires a "salt value" always. "salt" should be able to be omitted. My proposal is to "make salt parameter required" and "let programmers specify not to use salt explicitly". HKDF has a number of different applications: > a) Derive multiple strong keys from strong keying material. Typical case > for this is deriving independent encryption and authentication keys from a > master key. This requires only specification of $length. A salt is neither > necessary nor useful in this case, because you start with strong > cryptographic keying material. > b) Generating per-session (or similar) keys from a (strong cryptographic) > master key. For this purpose you can specify the $info parameter. again, a > salt is neither necessary nor useful in this case. (You could probably also > use $salt instead of $info in this case, but the design of the function > implies that $info should be used for this purpose.) > c) Extracting strong cryptographic keying material from weak cryptographic > keying material. Standard example here is extracting strong keys from DH > g^xy values (which are non-uniform) and similar. This is the usage that > benefits from a $salt. > d) Combinations thereof. > > Remember that HKDF is an extract-and-expand algorithm, and the extract > step (which uses the salt) is only necessary if the input keying material > is weak. We always include the extract step for compatibility with the > overall HKDF construction (per the RFCs recommendation), but it's > essentially just an unnecessary operation if you work on strong keying > material. > I'm aware of use cases, but your explanation is mandatory for discussion so that everyone understand it. Thank you. The only thing that we may want to discuss is whether we should swap the > $info and the $salt parameters. This depends on which usage (b or c) we > consider more likely. > Swapping $info and $salt parameter order will encourage users to use $salt when this is possible. I would recommend $salt use whenever possible. It is possible for many use cases. i.e. Modern applications set random values for security reasons and developers should set it for HKDF also. Developers are better to have secret salt whenever it is possible. Consider following following attack scenario: - password_hash() output is used for $ikm - hash_hkdf() output without salt is used for encryption key - app has SQL injection vulnerability and password hashes are stolen Attackers are easily decrypt encrypted data by generating key from password hash because salt is not used. Apps can have additional security by using salt defined as configuration parameter. IMO, this kind of usage would be the most common usage with PHP. Therefore, making salt a required parameter encourages users to adopt better security. > 2) Add hash function whitelisting >> >> There is hash function blacklisting which disallows insecure usage. It's >> good enough for now, but whitelisting would help in 3 ways. >> >> 1. Warn obsolete hash function usage. e.g. md2() >> >> 2. When new hash function is added and blacklist update is >> forgotten, whitelist mitigate it. >> (We are better to have .phpt for it to notify problem to new hash >> function author) >> >> 3. Raise E_RECOVEREABLE _ERROR for blacklisted hashes. >> Note: Blacklisted hash usage results in returning FALSE. This may >> result in very weak encryption/etc with @ operator, for example. >> > > The blacklist is an intermediate solution for PHP 7.1. For master the > information on whether a hash function is cryptographic will be integrated > into the hash ops and we will check against this value. The check will also > be expanded to HMAC and PBKDF2. > Sounds good. Note that the reason we're doing these checks is not to discourage use of > obsolete hash functions, but because the HMAC construction has certain > requirements on the hash function, which are generally not satisfied by > non-cryptographic hashes. In particular, HMAC requires a block-based hash > where the block size is greater than or equal to the digest size. > "md2" for HKDF does not make sense, but we may document that stronger hash provide more security than weaker one. Let's recommend SHA-3 in document. I prefer to warn weak/obsolete hash usage to users, but documentation would work also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
