Minimum length of salt and info for HKDF

Question

Hi newbie here is there any minimum length for salt and info passed to hkdf based key derivation or is using 32 byte randomly generated bits for salt and info can be used for all hkdf

Answer 1

There is no minimum length for either the salt or the info string in HKDF. In fact, they can both be omitted if your particular application does not need them.

The only real requirement is that the pair (salt, info) should be unique for each derived subkey — since, if it is not, then identical input keying material (which could occur for reasons outside your control, e.g. due to an insufficiently random password used to generate the IKM) will produce identical output, which is generally not desired.

More specifically, for HKDF, you can think of the salt as something that ensures that (accidentally or deliberately) reusing the same IKM for two applications (or two instances of the same application) will still yield different PRKs, and thus different OKM. Meanwhile, the info string allows several distinct and quasi-independent OKMs (such as separate keys for encryption and authentication, or a separate key for each of several messages, etc.) can be derived from one PRK, which is useful for many applications and makes the KDF more versatile.

For a typical application, the salt might be randomly generated, while the info string might be fixed for each distinct type of OKM needed by the application (e.g. "enc" and "auth") or it could be a unique message/file/account identifier, or perhaps a combination of the two.

For a randomly generated salt, you'll want to make it long enough to assign a unique salt to each IKM/PRK, and then — due to the birthday paradox — make it twice as long. This will, with high probability, ensure that all your salts will be unique. So, for example, a 32-bit salt would be enough if you only expect to need to derive at most $2^{16} = 65536$ different PRKs, while a 64-bit salt would be good for up to $2^{32} \approx$ 4 billion uses.

In practice, you can just use a random 128-bit salt (or e.g. a version 4 UUID) and not worry about salt uniqueness.

For further information, see sections 3.1 ("To Salt or not to Salt") and 3.2 ("The 'info' Input to HKDF") in RFC 5869.