views:

324

answers:

3

There are many articles and quotes on the web saying that a 'salt' must be kept secret. Even the Wikipedia entry on Salt:

For best security, the salt value is kept secret, separate from the password database. This provides an advantage when a database is stolen, but the salt is not. To determine a password from a stolen hash, an attacker cannot simply try common passwords (such as English language words or names). Rather, they must calculate the hashes of random characters (at least for the portion of the input they know is the salt), which is much slower.

Since I happen to know for a fact that encryption Salt (or Initialization Vectors) are OK to be stored on clear text along with the encrypted text, I want to ask why is this misconception perpetuated ?

My opinion is that the origin of the problem is a common confusion between the encryption salt (the block cipher's initialization vector) and the hashing 'salt'. In storing hashed passwords is a common practice to add a nonce, or a 'salt', and is (marginally) true that this 'salt' is better kept secret. Which in turn makes it not a salt at all, but a key, similar to the much clearly named secret in HMAC. If you look at the article Storing Passwords - done right! which is linked from the Wikipedia 'Salt' entry you'll see that is talking about this kind of 'salt', the password hash. I happen to disagree with most of these schemes because I believe that a password storage scheme should also allow for HTTP Digest authentication, in which case the only possible storage is the HA1 digest of the username:realm:password, see Storing password in tables and Digest authentication.

If you have an opinion on this issue, please post here as a response.

  1. Do you think that the salt for block cipher encryption should be hidden? Explain why and how.
  2. Do you agree that the blanket statement 'salts should be hidden' originates from salted hashing and does not apply to encryption?
  3. Sould we include stream ciphers in discussion (RC4)?
A: 

Like LFSR Consulting says:

There are people that are much smarter than you and I that have spent more time thinking about this topic than you or I ever will.

Which is a loaded answer to say the least. There are folks who, marginally in the honest category, will overlook some restraints when money is available. There are a plethora of people who have no skin at the fire and will lower the boundaries for that type,....

then, not too far away, there is a type of risk that comes from social factors - which is almost impossible to program away. For that person, setting up a device solely to "break the locks" can be an exercise of pure pleasure for no gain or measurable reason. That said, you asked that those who have an opinion please respond so here goes:

  1. Do you think that the salt for block cipher encryption should be hidden? Explain why and how.

Think of it this way, it adds to the computational strength needed. It's just one more thing to hide if it has to be hidden. By and of it's self, being forced to hide ( salt, iv, or anything ) places the entity doing the security in the position of being forced to do something. Anytime the opposition can tell you what to do, they can manipulate you. If it leaks, that should have been caught by cross-controls that would have detected the leak and replacement salts available. There is no perfect cipher, save otp, and even that can be compromised somehow as greatest risk comes from within.

In my opinion, the only solution is to be selective about whom you do any security for - the issue of protecting salts leads to issues that are relevant to the threat model. Obviously, keys have to be protected. If you have to protect the salt, you probably need to review your burger flippin resume and question the overall security approach of those for whom you are working.

There is no answer, actually.

  1. Do you agree that the blanket statement 'salts should be hidden' originates from salted hashing and does not apply to encryption?

Who said this, where, and what basis was given.

  1. Should we include stream ciphers in discussion (RC4)?

A cipher is a cipher - what difference would it make?

Nicholas Jordan
+2  A: 

If you are talking about IV in block cipher, it definitely should be in clear. Most people make their cipher weaker by using secret IV.

IV should be random, different for each encryption. It's very difficult to manage a random IV so some people simply use a fixed IV, defeating the purpose of IV.

I used to work with a database with password encrypted using secret fixed IV. The same password is always encrypted to the same ciphertext. This is very prone to rainbow table attack.

ZZ Coder
Yes, I'm talking about IV in block cipher and the dangers of reusing the same IV for repeated encryption.
Remus Rusanu
Why on earth would a "secret IV" weaken a cipher in any way? The main criteria for a good IV is to never use the same one. A secret cipher that changes is just as good as a public one that changes...
James
How are you going to keep track of the changing IV if it's secret? You need both the key and IV to decrypt so IV can't be encrypted. The only practical way to keep it secret is to use a fixed value, almost like an extension to the key.
ZZ Coder
A: 

Do you think that the salt for block cipher encryption should be hidden? Explain why and how

No it shouldn't. The strength of a block cipher relies on the key. IMO you should not increase the strength of your encryption by adding extra secrets. If the cipher and key are not string enough then you need to change the cipher or key length, not start keeping other bits of data secret. Security is hard enough so keep it simple.

Patrick