Hi, On Sat, Feb 4, 2017 at 7:49 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> > 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. >> >> > s/normally/ever/ > 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... > > Have *you* read anything else in the RFC? The reason why its authors have to recommend salt usage is because it is *otherwise the only optional part of the algorithm*. Cheers, Andrey.
