[cryptography] HKDF salt

Michael Rogers michael at briarproject.org
Thu Aug 1 05:47:19 EDT 2013


-----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 cryptography at randombit.net 
> 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-----


More information about the cryptography mailing list