On Sun, Feb 5, 2017 at 1:20 AM, Tom Worster <f...@thefsb.org> wrote: > On 3 Feb 2017, at 18:56, internals-digest-h...@lists.php.net wrote: > > HKDF w/o salt is OK, but with salt, it's much stronger than w/o it. >> > > That's not correct. > > The salt defends against certain attacks on predictable input key > material, i.e. weak passwords. But HKDF should not normally be used for > passwords because it is unsuitable. > > Excuse me. Have you ever read the RFC? https://tools.ietf.org/html/rfc5869
3.1 <https://tools.ietf.org/html/rfc5869#section-3.1>. To Salt or not to Salt HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. * We stress, however, that the use of salt adds significantly to the strength of HKDF*, ensuring independence between different uses of the hash function, supporting "source-independent" extraction, and strengthening the analytical results that back the HKDF design. Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of Krawczyk & Eronen Informational [Page 4] ------------------------------ <https://tools.ietf.org/html/rfc5869#page-5>RFC 5869 <https://tools.ietf.org/html/rfc5869> Extract-and-Expand HKDF May 2010 HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2 <https://tools.ietf.org/html/rfc5869#ref-IKEv2>]). Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. *Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material*; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. *It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee.* An example of such application is IKEv1 in its "public-key encryption mode", where the "salt" to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key. I'm a bit tired with people posting nonsense comment without reading references... Unlike RFC states, typical PHP use cases are able to use salt. > There is something like a weird pattern to your attempts to help PHP > programmers use the wrong function for the job -- HKDF for passwords, > uniqid and mt_rand for unpredictable randoms. > Do you know uniqid()'s entropy is extremely weak? Do you know current mt_rand()'s extropy is extremely weak? Are you saying current implementation is the best way that it should be? If you think so, please explain why these aren't weak and implementation is optimal. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
