Mixing
Why do some key derivation functions (like PBKDF2) use a salt?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
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.
key-derivation salt
asked 3 hours ago
Aran-Fey
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
3
down vote
favorite
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.
key-derivation salt
asked 3 hours ago
Aran-Fey
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.
– SEJPM♦
2 hours ago
@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.)
– Aran-Fey
2 hours ago
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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.
key-derivation salt
asked 3 hours ago
Aran-Fey
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.
key-derivation salt
key-derivation salt
asked 3 hours ago
Aran-Fey
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
Aran-Fey
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 hours ago
asked 3 hours ago
Aran-Fey
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
Aran-Fey
1184
asked 3 hours ago
Aran-Fey
1184
1184
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Aran-Fey is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.
– SEJPM♦
2 hours ago
@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.)
– Aran-Fey
2 hours ago
add a comment |Â
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.
– SEJPM♦
2 hours ago
@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.)
– Aran-Fey
2 hours ago
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.
– SEJPM♦
2 hours ago
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.
– SEJPM♦
2 hours ago
@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.)– Aran-Fey
2 hours ago
@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.)– Aran-Fey
2 hours ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
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.
answered 2 hours ago
fgrieu
73.6k6151313
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)?
– Aran-Fey
1 hour ago
1
@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.
– fgrieu
59 mins ago
add a comment |Â
up vote
1
down vote
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
answered 1 hour ago
Nate
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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?
– Aran-Fey
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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.
answered 2 hours ago
fgrieu
73.6k6151313
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)?
– Aran-Fey
1 hour ago
1
@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.
– fgrieu
59 mins ago
add a comment |Â
up vote
2
down vote
accepted
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.
answered 2 hours ago
fgrieu
73.6k6151313
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)?
– Aran-Fey
1 hour ago
1
@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.
– fgrieu
59 mins ago
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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.
answered 2 hours ago
fgrieu
73.6k6151313
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.
answered 2 hours ago
fgrieu
73.6k6151313
edited 56 mins ago
answered 2 hours ago
fgrieu
73.6k6151313
answered 2 hours ago
fgrieu
73.6k6151313
answered 2 hours ago
fgrieu
73.6k6151313
73.6k6151313
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)?
– Aran-Fey
1 hour ago
1
@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.
– fgrieu
59 mins ago
add a comment |Â
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)?
– Aran-Fey
1 hour ago
1
@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.
– fgrieu
59 mins ago
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)?
– Aran-Fey
1 hour ago
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)?
– Aran-Fey
1 hour ago
1
1
@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.
– fgrieu
59 mins ago
@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.
– fgrieu
59 mins ago
add a comment |Â
up vote
1
down vote
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
answered 1 hour ago
Nate
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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?
– Aran-Fey
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
add a comment |Â
up vote
1
down vote
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
answered 1 hour ago
Nate
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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?
– Aran-Fey
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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
answered 1 hour ago
Nate
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
answered 1 hour ago
Nate
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 1 hour ago
Nate
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 1 hour ago
Nate
111
answered 1 hour ago
Nate
111
111
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Nate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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?
– Aran-Fey
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
add a comment |Â
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?
– Aran-Fey
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
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?
– Aran-Fey
1 hour ago
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?
– Aran-Fey
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
In some ways it's belt and braces, but it protects against weaknesses in the IV being pseudorandom rather than truly random.
– Nate
1 hour ago
add a comment |Â
Aran-Fey is a new contributor. Be nice, and check out our Code of Conduct.
Aran-Fey is a new contributor. Be nice, and check out our Code of Conduct.
Aran-Fey is a new contributor. Be nice, and check out our Code of Conduct.
Aran-Fey is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f62807%2fwhy-do-some-key-derivation-functions-like-pbkdf2-use-a-salt%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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.
– SEJPM♦
2 hours ago
@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.)– Aran-Fey
2 hours ago