12
$\begingroup$

Let me start by explaining my understanding of the various concepts involved in this question:

  • Salt: Random bytes of data used as secondary input for a password hashing function, like so:

    hashfunc(<password>, <salt>) -> <hash>

    And both the <hash> as well as the <salt> that was used are then stored (in a database, for example).

    This prevents attacks using rainbow tables, making it more difficult for an attacker who has access to the output of the hash function (<salt> + <hash>) to deduce the original <password>.

  • Key derivation function: A function that takes a password <password> and an integer <size> as input, and generates arbitrary bytes of the desired <size> as output, like so:

    kdf(<password>, <size>) -> <bytes of length <size>>

    This allows us to turn a plain-text password like "admin123" into a key of a certain size that can be used by other cryptographic functions (like AES encryption, which requires a key of size 32).

So if my understanding is correct, then key derivation functions have no use for a salt. After all, the derived key isn't intended to be stored - it'll be used as input for another cryptographic function, and then it'll simply be discarded. Unless someone steals the derived key from the computer's memory in this short time frame, there is no risk of a rainbow table attack.

And yet, according to wikipedia, the PBKDF2 key derivation function takes a salt as input:

The PBKDF2 key derivation function has five input parameters:

DK = PBKDF2(PRF, Password, Salt, c, dkLen)

What purpose does this salt serve? Did I misunderstand the purpose of key derivation functions?

Related questions:

  • PBKDF2 and salt does not answer my question because the answers seem to assume that the derived key will be stored, which, according to my understanding of key derivation functions, should never happen.
Improve this question
$\endgroup$
4
  • $\begingroup$ Note that an attacker can probably "interpret" the ciphertext as a hash and still construct a rainbow table that way when using a simple saltless KDF. $\endgroup$
    – SEJPM
    Commented Oct 2, 2018 at 13:54
  • $\begingroup$ @SEJPM Sorry, I don't quite understand what you're saying. Say I use a saltless KDF to generate a key for AES encryption. The encrypted data would start with the IV that was used to initialize the cipher, and everything after that would be the actual encrypted data: <IV><file>. Now if I use a KDF with a salt instead, then I would have to store that salt, giving me a result of <salt><IV><file>. How would that be any different from simply using a longer IV? (I know that AES only supports IVs of a certain size, but it's a theoretical question.) $\endgroup$
    – Aran-Fey
    Commented Oct 2, 2018 at 14:10
  • $\begingroup$ While this is a good counter-example to my comment if the IV is randomised, it is less so if the IV is deterministic and eg always starts at 0 and counts up. $\endgroup$
    – SEJPM
    Commented Oct 2, 2018 at 17:11
  • $\begingroup$ you always (well shouldv'e) used a salt with a hashed password, hashing speed doesn't affect that. $\endgroup$
    – dandavis
    Commented Oct 2, 2018 at 19:44

2 Answers 2

Reset to default
8
$\begingroup$

PBKDF2, like most password-based key derivation functions, has a salt input because that is often useful. Two examples:

  • When using PBKDF2 as a key derivation function, the salt allows to re-use the same master key for multiple derived keys, e.g. a confidentiality key and integrity keys, with a different salt per use. In the same vein, PBKDF2 could be used to generate per-site passwords from a master password and the site name as salt.
  • When using PBKDF2 for storage of access-control password tokens, salt will make brute-force attack impossible to carry before the salt is known, defeating rainbow tables. That's noted in the question.
Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ If I understand correctly, you're saying that PBKDF2 takes a salt as input so that it may be used to generate keys that can safely be stored permanently, right? So then if I'm not planning to store the derived key, there is no harm in using a hard-coded salt (or no salt at all)? $\endgroup$
    – Aran-Fey
    Commented Oct 2, 2018 at 14:18
  • 2
    $\begingroup$ @Aran-Fey: I have not implied that the PBKDF2 output is "stored permanently". It is entirely reasonable that the key is recomputed with PBKDF2 each time it is used. That would typically be the case if PBKDF2 was used to generate per-site passwords from a master password and the site name as salt. One issue if using a hard-coded salt (or no salt at all) for PBKDF2 is that, when in addition the input key is low-entropy (such as a password), one knowing the salt (or absence thereof) in advance can precompute hashes and carry an attack faster. $\endgroup$
    – fgrieu ♦
    Commented Oct 2, 2018 at 15:12
3
$\begingroup$

It helps mitigate against known plaintext attacks (wiki article). i.e. is you have a several documents that have been encrypted with the the same derived key and one or more documents encrypted with the derived key are known* then it is possible to try and identify the key from comparing the unencrypted document and the encrypted one.

Two users encrypting the same document independently could use the same password (especially if a weak passwords are commonly in used). If a unique Salt is added for each user this will not be apparent from simply comparing the encrypted documents.

Similarly is a unique salt is added to each document will mean that while it is possible to obtaining the key for the known document - the key for other documents will still be secret and a rainbow table approach to identify the password used to create for the key will still not be possible.

Note "document" is used as a generic term for the item to be encrypted

2: or can be guessed/derived in some way

Improve this answer
$\endgroup$
2
  • $\begingroup$ I understand that encrypting multiple files with the same key gives a potential attacker some information about the key, but isn't that why every encryption algorithm worth its salt (pun intended) uses an IV? Even if you encrypt two identical files, the ciphertext won't be identical because they both use a different random IV. The salt and the IV both exist to solve the same problem, no? Surely there's no need to use both of them? $\endgroup$
    – Aran-Fey
    Commented Oct 2, 2018 at 14:29
  • $\begingroup$ In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random. $\endgroup$
    – Nate
    Commented Oct 2, 2018 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.