[cryptography] HKDF salt
iang at iang.org
Thu Aug 1 05:41:49 EDT 2013
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
. 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  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.
 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.
> 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"?
> 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.
More information about the cryptography