[cryptography] HKDF salt

Michael Rogers michael at briarproject.org
Thu Aug 1 05:16:51 EDT 2013


-----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.
   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. 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?

   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?

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?

Thanks,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR+ieDAAoJEBEET9GfxSfMVsIH/3dsAhF4FukIcdVLa/Kw782A
akbTjnYHAvwdvRi3fVBrXejM3csya9psSu2qVIgAUXWaMxRVcvPkUoTc7NF+MC65
xVS4j1YcmkEQL7L7LnUQVukISzBO3NgwmAKPrxdzeXLJlaiL9N51ecYmjC0jo9Ou
dHs9108z2AQHYZ/n4PhRCVdSPjIA5/Z6kusu6cOQsZHTzeNbmoTuOafZTHFkESbX
TmSVS4m54vgQWukTsjGsHDDoemvGzY4ahfZj8l+oOSr3OUP3MdYaxaQEXxq6ZQ3L
fdNkdxnpOznz+e14RQzIOFjr8QbWBjwlGFp5CxaMPgKL9a5cKuU9JIxjLsUWyXs=
=ZaC7
-----END PGP SIGNATURE-----


More information about the cryptography mailing list