# PBKDF2 Salt and Password Ordering

I am currently reading about PBKDF2, and understand that the salt is used only once, while the password is used multiple times in the computation of the final key (see this question). How would the integrity of PBKDF2 change if the roles of password and salt are changed?

• Does it matter? One of these approaches has withstood years of use and examination by cryptographers. The other has not. Aug 26, 2014 at 17:28
• @StephenTouset Simple, I've seen a few implementations on stackoverflow where the salt and password were switched by mistake (I hope). Both are just byte arrays for PBKDF2. In that case you may want to know what you ended up with (after inheriting the system from the previous developer) :) Aug 26, 2014 at 17:35
• Also, it helps to further my (and hopefully others) understanding of the algorithm. There was a design decision to construct PBKDF2 in such a way, and I would like to know why. Aug 26, 2014 at 17:36
• In how far does the fourth paragraph of D.W.'s answer not answer your question as well? Aug 26, 2014 at 17:39
• That's fair. :) There are a lot of questions here that are thinly-veiled fronts for, "I think I know more than experienced cryptographers, and would like to use preexisting algorithms in strange and confusing ways to increase their security. Is anyone here willing to validate my decisions?" It's useful to weed these types of questions out. Aug 26, 2014 at 17:39

PBKDF2 is defined for an arbitrary PRF, but in practice HMAC is usually used. Either with SHA-1 (original definition), SHA-256 (e.g. in scrypt) or even SHA-512-256 (NaCL). So first you can look at how swapping key and message affects HMAC.

HMAC has two cases depending on the length of the key: if it's no longer than the block size of the hash, it is used as is; if it's longer it is first hashed. After that, two keys are derived by XORing it with pads and the final function is:

$$H(k_1||H(k_2||m))$$

This leads to two reasons to prefer the defined order to the swapped one:

1. For every key shorter than the blocksize, there's an equivalent key $k' = k||0$, where a zero byte is appended. For every key longer than the block size, there's another key $k' = H(k)$ which is equivalent.

For randomly generated keys, or even passwords, these do not matter in practice. If you used a message in that position, however, it would be malleable – you could swap a long message with a gibberish one and use the same MAC value.

2. The key derivation through hash and/or XOR, as well as the initial block of each of the two hashes can be calculated once for a given key and used for many messages. In the swapped order everything would have to be calculated again.

Neither of these is a problem in PBKDF2, if you use a constant width salt, like a 256-bit random number. The first can only happen if two distinct salts can collide, which – barring an actual hash collision – requires them to be different length. The second doesn't matter, since many iterations are done with the same $k$ whether it's the password or the salt. (Swapping makes it an inconsequential amount faster to try multiple passwords against one salt.)

Additionally, swapping the order will not make finding a preimage any easier, unless the hash is broken. Since preimage resistance is what a password hash in concerned with, HMAC with arguments swapped should be OK.

(The above is not true for all MACs. For example, it is trivial to find some preimages for CBC-MAC with a known key.)

Regarding PBKDF2 itself, there's the additional fact that the password (i.e. HMAC key) is a part of every hash iteration, while the salt is only used once. This affects the cycles the hash can enter. With a constant salt as the HMAC key, every possible password would enter the same set of cycles. Since it only happens after around $2^{80}$ iterations for SHA-1, it too doesn't matter, even if it was somehow exploitable.

In conclusion, then, swapping the password and salt with PBKDF2-HMAC seems secure. With another PRF it could be insecure. Swapping them in HMAC for many other uses is also insecure. However, there is no good reason to swap them, so you should still use the normal defined order.