2

Let's say that a random key is derived using the following function (PBKDF2).

key = fn(password, salt, iterations)

Q1: How can I reverse engineer the salt from the password, iterations, and the key?

Q2: If the same salt is used for generating the key, how can I reverse engineer the salt from the password, iterations, and the key?

Sayan Pal
  • 123
  • 5
  • Brute force (good luck with that as the recommended minimum salt length for PBKDF2 is 16 bytes) But in the real world the salt is not a secret so there's no need to try to find it, it's the key that's the secret. – Swashbuckler Sep 17 '21 at 21:12
  • Even with Brute force, how difficult it can get? – Sayan Pal Sep 17 '21 at 21:15
  • I don't understand how the second question is different from the first. You say "same salt", but what's it the same as? – Gordon Davisson Sep 18 '21 at 09:52
  • @GordonDavisson A fixed salt is used to derive the keys. However, a new password and iteration are generated every time. So the question really is that if or how the salt can be reverse engineered by mining the password, iterations, and the key? – Sayan Pal Sep 18 '21 at 12:32

1 Answers1

3

PBKDF2 is based on HMAC using a cryptographically secure hash function. Assuming the hash function is secure, the easiest approach will be brute force. Assuming you know the password, then the difficulty is the amount of entropy in the salt. So if you picked 16 random bytes, that provides 128 bits of entropy, and you'll require more energy than is required to boil all the world's oceans. 16 or 32 random bytes are customary amounts of salt to use when no other guidelines are given, both of which will be computationally infeasible to guess.

In general, we don't consider salt to be secret. It is generally stored along with the iteration count in plaintext when storing passwords, and in cryptographic protocols like TLS and SSH, the salt is sent in plaintext as part of the cryptographic negotiation.

bk2204
  • 3,246
  • 6
  • 12