3
$\begingroup$

For optimum security, a random salt should be chosen for PBKDF2.

I came across a scenario where I produce a hash of a random file that serves as the "password". Due to the nature of files, this has similar entropy issues as a "normal" password.

What would happen now if I decided to take the same (low-entropy) hash as the salt, too? Is there a known attack on this? Of course, in this scenario the salt would be kept secret. But still, since it is not entirely random, does this compromise the overall security, and if so, how badly? I know that for example "key as IV" severely compromises certain ciphers, so I'm afraid it could do harm in this situation, too.

$\endgroup$

1 Answer 1

4
$\begingroup$

Using the password itself (or anything similar predictable) instead of an independent random value as the salt denies the whole benefit of salt:

  • Same passwords (passphrases) give now the same key, instead a different one. So, if two users happen to choose the same favorite image as their password, they get the same key, and thus an attacker can use this fact to easier get the key.
  • If an attacker bruteforces your "password" database, he can attack multiple passwords in parallel, since they don't use different (independent) salts.

If you have a way to generate good quality random numbers (which should be the case on every normal personal computer), generate a random salt and put it at the start of your encrypted file (like a normal initialization vector).

$\endgroup$
2
  • $\begingroup$ I should have added this, actually same files yielding the same output is a feature, not a bug :) The entire scheme is a "convergent encryption" scheme. This means that given the same file, both parties need to be able to come up with the same salt, too. That's why the initial idea was to just reuse the file hash for the salt. But you're still right, I see now that doing so would kind of take the whole parallelization aspect of the salt away. Thanks! $\endgroup$
    – emboss
    Feb 13, 2012 at 18:52
  • $\begingroup$ Have a look at the convergent-encryption tag for some earlier discussions of this. Though I'm not sure what one could really do here, other than a really big work factor, to prevent brute-forcing. $\endgroup$ Feb 13, 2012 at 22:09

Your Answer

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

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