I've been looking over the HKDF specs (RFC 5869), and something I noticed is that in the
salt are reversed:
2.2. Step 1: Extract HKDF-Extract(salt, IKM) -> PRK Options: Hash a hash function; HashLen denotes the length of the hash function output in octets Inputs: salt optional salt value (a non-secret random value); if not provided, it is set to a string of HashLen zeros. IKM input keying material Output: PRK a pseudorandom key (of HashLen octets) The output PRK is calculated as follows: PRK = HMAC-Hash(salt, IKM)
Neither the spec nor the paper seem to address the order.
To me it seems like
HMAC(salt, IKM) would be weaker against a brute force search of
IKMs, as the digest of the
salt can in this case be precalculated by an attacker (assuming the
salt is a non-secret value or zero).
What is the benefit of using it this way?