-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Ian! I hadn't considered dictionary attacks because I was assuming the initial keying material had enough entropy to make them impractical. But now I can see that was my assumption, not the HKDF designers'.
Cheers, Michael On 01/08/13 10:41, ianG wrote: > In general: the purpose of the salt technique is to stop > dictionary attacks. > > Say you have a password 'fred' and the hash function is a variant > of DES [0]. It is possible to calculate the DES hash of 'fred' and > store that. Then, in every system, I can simply read the hashed > passwords by cat /etc/passwd [0] and compare to known results in my > dictionary. > > However, if the hash function combines 'fred' with salt 948375384 > and then stores the two together in the file, the dictionary attack > fails. In effect, the space is expanded so dramatically that I can > no longer calculate 'fred' with every possible salt and store it, > economically. > > > [0] these things were true a long time ago... > > > in more particular: > > > On 1/08/13 12:16 PM, Michael Rogers wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Hi all, >> >> I wonder if anyone on the list can help me to understand the >> purpose and correct use of HKDF's salt parameter. RFC 5869 has >> this to say: >> >> HKDF is defined to operate with and without random salt. This >> is done to accommodate applications where a salt value is not >> available. > > > As a quibble, this is a bad idea. It should be designed this way: > > HKDF is defined to operate with a salt, always. Where applications > cannot provide a salt, a zero-filled salt should be supplied. > > This is a question of software engineering, and robustness. > >> 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 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]). >> >> My understanding of the above is that the salt doesn't increase >> the entropy of HKDF's output from the adversary's point of view, >> since the adversary knows the salt value. > > > Yes. > >> However, the salt prevents accidental collisions if identical >> initial keying material is used in multiple application domains. > > > Not accidental, but calculated in advance. > >> Is that right? Can anyone shed light on the meaning of >> "source-independent extraction"? > > hmmm... > > >> The RFC continues: >> >> 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. >> >> This doesn't sit well with my interpretation above, because it >> suggests that the salt contains entropy (from someone's point of >> view) that contributes to the security of HKDF's output. But how >> can the salt be said to contain entropy when its value is >> non-secret? > > > The entropy is provided to ensure lack of collisions in selection. > If everyone selects from a good random source, then there is a good > spread across the space, enlarging the task of dictionary attacks. > > >> 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. >> >> This seems unsurprising - if the salt value is unknown to the >> adversary then clearly it can contribute entropy to HKDF's >> output. >> >> Going back to the issue of non-secret salt, here's a thought >> experiment: we generate a random salt value, publish it in the >> New York Times, and use it for all calls to HKDF in a certain >> application domain. Is this somehow more secure than using no >> salt? If so, can you help me to understand how? > > > No, because it is the same value for every different call to HKDF, > so in effect it is not a salt at all. In more conceptual terms you > are simple changing the algorithm of the hash function, and not in > any significant way. > > >> Less extremely: each time we use HKDF, we generate a fresh random >> salt value and publish it in the New York Times. Is this more >> secure than using no salt? How? > > > Yes, consider the task of the dictionary attacker. > > > > iang _______________________________________________ cryptography > mailing list [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR+i6nAAoJEBEET9GfxSfMSnsIAKwRToNFgWPhQpp6N/PcWxbz +N/KHp4o/nAK/43TsnbV0IrHTs8xVP4gYmRhi+NLKuSO0uarOU7CJtLAZCyKyMSy PmK7jU6EbY7YyUfWF/R93CKZFNuWtiM8qRsfvhwtyfv7IZZbPpgXOYTy+7UHbM5v pytbIJ6vWtAw7YfA1xwxH7NTugFIWAuEZgsZRx3jTV68XFNBRHv8vXXY4ybqZvnm cHsGCsR1PXjTZv7H4wv3cNACbHc3O3g04IzlnO+BSVmOVoSdl6ueUmQv9QqsqM+j urIdg0Z+d/GHpDS7Vk+Fz9jTMSJp+aKSE33Igbd4s/nSs+oz7Av9KwatmM2lP6g= =3cBX -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
