39

If I am using Rijndael CBC mode, I have no idea why we would need salt. My understanding is even if people know the password, but he cannot get the data without IV. So from my perspective, password + IV seem to be sufficent secure.

Do I get anything wrong?

Kelvin
  • 993
  • 2
  • 10
  • 16

3 Answers3

52

Yes, you need all of these things.

Salt (and an "iteration count") is used to derive a key from the password. Refer to PKCS #5 for more information. The salt and iteration count used for key derivation do not have to be secret. The salt should be unpredictable, however, and is best chosen randomly.

CBC mode requires an initialization vector. This is a block of random data produced for each message by a cryptographic random number generator. It serves as the dummy initial block of ciphertext. Like the key-derivation salt, it doesn't have to be kept secret, and is usually transmitted along with the cipher text.

The password, and keys derived from it, must be kept secret. Even if an attacker has the parameters for key derivation and encryption, and the ciphertext, he can do nothing without the key.

Update:

Passwords aren't selected randomly; some passwords are much more likely than others. Therefore, rather than generating all possible passwords of a given length (exhaustive brute-force search), attackers maintain a list of passwords, ordered by decreasing probability.

Deriving an encryption key from a password is relatively slow (due to the iteration of the key derivation algorithm). Deriving keys for a few million passwords could take months. This would motivate an attacker to derive the keys from his most-likely-password list once, and store the results. With such a list, he can quickly try to decrypt with each key in his list, rather than spending months of compute time to derive keys again.

However, each bit of salt doubles the space required to store the derived key, and the time it takes to derive keys for each of his likely passwords. A few bytes of salt, and it quickly becomes infeasible to create and store such a list.

Salt is necessary to prevent pre-computation attacks.

An IV (or nonce with counter modes) makes the same plain text produce different cipher texts. The prevents an attacker from exploiting patterns in the plain text to garner information from a set of encrypted messages.

An initialization vector is necessary to hide patterns in messages.

One serves to enhance the security of the key, the other enhances the security of each message encrypted with that key. Both are necessary together.

erickson
  • 249,448
  • 50
  • 371
  • 469
  • 2
    It's also worth saying that if you have everything but the IV, you can successfully decrypt everything but the first block of plaintext. – caf Dec 16 '09 at 08:17
  • If salt should be unpredictable then how come it does not have to be secrete? You have a wrong statement there. – Akash Kava Oct 27 '12 at 11:39
  • 3
    @AkashKava No, my statement is correct. An attacker cannot guess an *unpredictable* salt *before* it is chosen. If a salt is *secret,* an attacker would not be able to guess it even after it is chosen. Standards for password-based encryption protocols like [CMS](http://tools.ietf.org/html/rfc3211#section-2.1) specify that the [unencrypted salt can be sent](http://tools.ietf.org/html/rfc2898#appendix-A.2) along with the encrypted message. A predictable salt allows attackers to pre-compute encryption keys for common passwords and reuse that table many times to decrypt messages quickly. – erickson Oct 27 '12 at 17:01
  • I am still not convinced, what is benefit of keeping salt not secrete, fine here is my salt= a pretty good GUID, and i put it in public, I am helping attacker to reduce time by not guessing salt, what good does it do for security? – Akash Kava Oct 27 '12 at 17:12
  • 3
    @AkashKava "I am helping attacker to reduce time by not guessing salt." This is true only if your password is very weak, and the salt is responsible for the entropy in your derived key. If the password itself is strong, knowing the salt won't help the attacker. The secrecy of a password comes from its storage: in your brain or your wallet. How would you keep salt secret? If you could keep a salt secret, why would you need a password? The salt itself could be used as a pre-shared key in that case. Salt is *only* to prevent the attacker from pre-computing keys in a time-space trade-off. – erickson Oct 28 '12 at 00:19
  • From my reading this doesn't seem to be quite correct. If you use a unique initialization vector for each encrypted string, that serves as your salt, and you don't need a separate salt in addition to that. – user12861 Jul 09 '13 at 20:27
  • 2
    @user12861 The salt protects against pre-computed dictionary attacks. Suppose an attacker has a list of the most commonly chosen passwords. Deriving a key for each of them would take a long time (because of the "iteration count" of the KDF), but without salt, he only has to do it once and store the results. He could then very quickly attempt a decryption of a given message with each of these derived keys, looking for expected features of the plain text to see if he had a match. With salt, the space requirements for this attack become prohibitive. What were you reading to suggest otherwise? – erickson Jul 09 '13 at 20:45
  • If you're using initialization vectors properly, you use a different one of THOSE each time, and they are random. Thus they act as a salt, and include the advantages you mention. Will links work in comments? If so, try this: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/1e764175-0690-4fbb-a391-fca97913101d/salt-vs-initialization-vector – user12861 Jul 09 '13 at 21:20
  • 2
    @user12861 Initialization vectors provide cipher text indistinguishability; even though you may encrypt the same plain text with the same key multiple times, the resulting cipher texts will be different each time, and an attacker will be none the wiser. Reason with me: How does an IV provide any protection against pre-computed dictionary attacks? The linked posts don't say that using one obviates the need for the other. On the contrary, they are pointing out that salt and IV are completely distinct and unrelated. If one did away with the other, they wouldn't be unrelated. – erickson Jul 09 '13 at 22:16
  • The first post mentions that IVs also act as a type of salt. You can't pre-compute because you'd need to use every possible key, which isn't feasible (with the usual 2^256 possible keys), so that's off the table. Using a random IV will prevent the problem of using the same plain text multiple times giving the same encrypted text, as you say. In that sense the IV acts as a salt. I think using random IVs is also important for other reasons, but the details are too long to explain in a comment. Since the IVs are random, they could prevent precomputation if that were possible. – user12861 Jul 09 '13 at 22:58
  • 2
    We are talking about *password-based encryption* here. Human beings don't choose keys from a 2^256 space with uniform probability. They use "password123". Knowing this, attackers routinely succeed in compromising poorly designed crypto systems with a dictionary that holds an infinitesimal fraction of possible keys. Without salt, pre-computed dictionaries are very much still on the table. That's why *the* standard for password-based encryption, PKCS #5, *requires* the use of salt, and it's why CMS (S/MIME) uses key derivation salts and cipher mode IVs (or nonces) together. They're orthogonal. – erickson Jul 09 '13 at 23:29
  • I see. It sounds like you know more about this stuff than me. Sorry to muddy the waters. – user12861 Jul 10 '13 at 12:33
  • 4
    @user12861 your questions got us some helpful answers, nothing is wasted – Riccardo Galli Jul 12 '13 at 15:28
  • Yes, I will update my answer to highlight some of this info. Thanks for challenging my answers. – erickson Jul 12 '13 at 16:02
  • @erickson I still don't understand why they are orthogonal. Are you saying that if the password is weak, like pass123, an attacker could pre-compute all possible ciphers given all possible IVs for the pass123 plaintext? Thus requiring the use of a salt on top of it to prevent this? I feel like pre-computing all possible IVs for a list of common passwords would take way too long to ever be possible, but I may be wrong. If so, I understand the use for a Salt, a Salt makes it impossible, since the attacker doesn't even know what to pre-compute. Otherwise, I'm not sure why salting would be needed. – Didier A. Aug 29 '13 at 18:49
  • @didibus No, not exactly. I added an *Updated* section to my answer. I hope that makes the point more clearly. – erickson Aug 29 '13 at 21:35
  • 1
    @erickson Ah, I think I understand. So the Salt will not only make the passwords more unique, it will actually make the generation of a rainbow table almost impossible, because it would take too much time to do and too much space to hold. And the IV will simply prevent blocks from encrypting to the same cipher, thus if you know that Obama encrypts to X and you see that other ciphers have X in them, chances are they talk about Obama, unless you used an IV, in which case, the pattern becomes moot since each encryption of Obama would give a different cipher. Does that sound correct? – Didier A. Aug 30 '13 at 14:25
  • This discussion *almost* answered my question, so I'll ask it: What would be wrong with using the same value for the IV and the salt? As others mentioned, both must be random, both are sent unencrypted along with the message. I understand that they have distinct purposes. But would it reduce security if one (random) value were used for both purposes? – jwd Jan 08 '15 at 22:31
  • @jwd If you only encrypt a single message with that password, I can't think of any security problems using the salt as the IV. However, most password-based encryption standards specify a structure for the key derivation parameters comprising salt and iterations, and most encrypted message format standards specify a structure that comprises the algorithm (including parameters) and the IV. So, if you're following a standard, rather than rolling your own, I can't think of any reason you'd want to recycle those random bits. – erickson Jan 08 '15 at 23:55
  • @erickson: do you know any links which mentions recommendations how to select the salt? (or IV for CBC?) – gmoniava Mar 10 '15 at 07:37
  • 1
    @Giorgi Yes, there are many such resources. One many would regard as authoritative is [NIST Special Publication 800-132;](http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf) §5.1 specifies that salt should be at least 128 bits and chosen by a cryptographic random number generator. Similarly, [NIST SP-800-38A](http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf) (see Appendix C) recommends two methods for selecting IVs: encrypting a nonce, or using a cryptographic RNG. – erickson Mar 10 '15 at 16:07
  • @erickson: thank you I think PKCS5 also says smth about salt, using that as reference is also ok? I will look into your links though!. ps. for IV I was thinking to refer to wikipedia it has some information too – gmoniava Mar 10 '15 at 18:21
  • @Giorgi PKCS #5 is a good reference too. Wikipedia should cite the NIST and PKCS documents; I wouldn't cite Wikipedia as a reference directly. – erickson Mar 10 '15 at 18:45
  • What course does one need to take to learn these? Cryptography 101? – Honey Oct 30 '20 at 16:25
8

First things first: Rijndael does not have a "password" in CBC mode. Rijndael in CBC mode takes a buffer to encrypt or decrypt, a key, and an IV.

A "salt" is typically used for encrypting passwords. The salt is added to the password that is encrypted and stored with the encrypted value. This prevents someone from building a dictionary of how all passwords encrypt---you need to build a dictionary of how all passwords encrypt for all salts. That was actually possible with the old Unix password encryption algorithm, which only used a 12-bit salt. (It increased the work factor by 4096). With a 128-bit salt it is not possible.

Someone can still do a brute-force attack on a specific password, of course, provided that they can retrieve the encrypted password.

However, you have an IV, which does pretty much the same thing that a Salt does. You don't need both. Or, rather, the IV is your salt.

BTW, these days we call "Rijndael" AES.

vy32
  • 24,271
  • 30
  • 100
  • 197
  • 2
    IV and salt serve similar purposes: they ensure that otherwise identical inputs produce unpredictable outputs. However, a key derivation salt does not obviate the need for an IV. By choosing a new IV for each message, the same password can be used to encrypt many messages. Even if some of the messages are identical, an attacker won't be able to tell. – erickson Dec 15 '09 at 22:34
  • It seems that the OP is using password-based-encryption with Rijndael CBC (and Rijndael and AES are not precisely the same thing - AES is effectively a subset of Rijndael; the former has a fixed 128 bit blocksize whereas the latter has a variable blocksize). – caf Dec 16 '09 at 08:15
  • 2
    Salts are used in hashing not encryption. – Lucas Kauffman Nov 21 '13 at 10:09
  • 2
    Salts are used in password hashing, which is sometimes done using cryptographic functions rather than hash functions. – vy32 Mar 10 '15 at 17:05
2

A salt is generally used when using a hash algorithm. Rijndael is not a hash, but a two-way encryption algorithm. Ergo, a salt is not necessarily needed for encrypting the data. That being said, a salted hash of a password may be used as the Key for encrypting data. For what you're looking for, you might wish to look at hybrid cryptosystems.

The Key should be considered private and not transmitted with your encrypted data while the IV may be transmitted with the encrypted data.

Jesse C. Slicer
  • 19,000
  • 3
  • 63
  • 80
  • 7
    Negative. The IV is not considered confidential and, in fact, needs to be stored with the encrypted data, or else the data cannot be decrypted. – vy32 Dec 15 '09 at 04:27
  • 1
    Jiminy Christmas, why a downvote, *downvoter*? I corrected this as per the comment EIGHT YEARS AGO. – Jesse C. Slicer May 19 '17 at 16:48