Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have mainly referred to this question. Definitely in case of using a salt, IV has a use of adding randomisation to each and every key. But isn't it redundant in case of using an IV to use a salt? (Like in case of referring to PBE with AES in CBC mode.)

(This is because in my understanding using the salt will make it not feasible to use rainbow tables or likes for brute force for each and every possible salt, and IV will further add randomisation to each and every message... But in case of using IV there will be randomisation in each and every message, so rainbow tables will not be feasible then also without using a salt.)

share|improve this question

migrated from security.stackexchange.com Jan 10 at 18:25

This question came from our site for information security professionals.

1  
I dont understand your question. A salt randomizes a hash to protect against rainbow tables. IVs make cryptoanalysis very hard. Thats two very different things. – marstato Jan 10 at 18:46
    
So if only an IV is used it won't protect against rainbow tables ? – Kaustubh Jan 10 at 18:48
    
If IV is used, it also generates a different hash for the same data, so I don't think rainbow tables can be used in that case too, when using IV making the use of salt with IV pointless,... Please correct me if I am wrong.. :) – Kaustubh Jan 10 at 18:51
1  
You are getting something wrong here: IVs are used in encryption, e.g. AES. Salts are used in hash functions. – marstato Jan 10 at 18:52
    
In the link I gave the main answer says that So, if you are using PBE with AES in CBC mode as the underlying cipher, you would expect to have to send both a PBE salt and a CBC IV along with the encrypted data , also this question of difference and need of the too came when I was searching for symmetric encryption in c# (link- stackoverflow.com/questions/202011/encrypt-and-decrypt-a-string) and here too both the salt and IV were used for a single encryption... – Kaustubh Jan 10 at 19:03
up vote 8 down vote accepted

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to the KDF, given that you're encrypting every message with a unique IV.

In general, the answer is "possibly, but at least using both won't hurt."

An IV and a salt really have two completely different security goals. An IV is used as part of the encryption process, and its main purpose is to allow the same key to be securely used to encrypt multiple messages.* If the same key and IV are used to encrypt more than one message, inspecting the ciphertexts can leak some information about the plaintexts.

(The exact information leaked depends on the cipher mode: for CBC and CFB modes, it includes the length of any common prefix shared by the messages, and possibly some information about the first cipher block that differs; for CTR and OFB modes, reusing the IV leaks the bitwise XOR of the full messages!)

A salt, on the other hand, is used in the key derivation process,** and its main purpose is to slow down certain kinds of brute-force password cracking attacks by, on one hand, ensuring that two users with the same passphrase won't end up with identical keys, and on the other hand, preventing attackers from precomputing passphrase/key combinations in advance.

(Some KDFs may also use the salt to allow multiple quasi-independent keys to be derived from the same passphrase, while other KDFs have a separate parameter for that. Similarly, some cipher modes may also have additional requirements on the IV; for example, CBC mode needs an IV that is not only unique but also unpredictable to resist certain chosen-plaintext attacks.)

In particular, a password-based key derivation function should implement key stretching, i.e. it should be deliberately resource-intensive to compute in order to slow down brute force attacks. Including a unique salt in this process is important, because it prevents an attacker from gaining a significant advantage by targeting multiple users in parallel.

Without a salt, an attacker could just run the slow key-derivation process once for each password, and then quickly test the resulting key against every captured message. Salting the KDF forces the attacker to instead repeat the slow key derivation process for each user / message separately. An IV will not help here, since it's applied only during the encryption step, after the slow key derivation process is over.

IVs don't really have any effect on brute-force password guessing attacks like this; the kind of attacks prevented by proper IV usage are plaintext-recovery (not key-recovery) attacks based on reusing the same key and IV to encrypt multiple message, which can leak information about the plaintexts for those messages.

Note that, if you're only encrypting a single message with each key produced by your KDF, then you may be able to safely use a fixed IV. But in that case, you definitely need to use a per-message salt in your KDF, to guarantee that the keys will really be unique. In any case, even if not strictly necessary in this case, using a random unique IV is still the safe default choice.

Ps. In any case, you really should be using an authenticated encryption mode instead of plain CBC to protect against active tampering attacks. Among such modes, I'd like to particularly mention SIV mode (RFC 5297), which is designed to offer extra resistance against accidental IV reuse.


*) At least, that's true of the kind of IVs we're talking about here. More generally, the term "IV" really just means "initialization vector", and is used for all sorts of algorithms, like hash functions, that involve iteratively processing blocks or "vectors" of data. Alas, the terminology is probably too entrenched to change at this point.

**) Salts are also used for password hashing in password-based authentication schemes. Actually, password hashing and key derivation are very similar tasks, and so the algorithms and terminology are mostly the same.


Related links:

share|improve this answer
    
Thanks a lot for the detailed help, but I got some doubts in the second last paragraph, please confirm. Before going into that I would like to mention that I have seen prominently single salt for user and different IV for each message and would be referring to it, if there is no issue. Supposing some unauthorised party gets a hold of my encrypted message with no salt but unique IV he still cannot use rainbow tables and has to check against all possible passwords with the IV in that message. Continued in next comment..... – Kaustubh Jan 10 at 19:49
    
So now brute-forcing with the IV in message he can find the message and the password in just one round of brute force. Whereas if I used a salt to which took a really resource intensive KDF, it would take him a really long time to brute force the possible password with the salt.... Thanks !! – Kaustubh Jan 10 at 19:53
1  
You definitely should use both a salt and an IV, unless you have some specific reason not to use both. Generally, the salt should be random, and long enough to be almost surely unique; the requirements for the IV depend on the cipher mode you're using; most modes just require the IV/nonce to be unique, but CBC mode specifically also requires it to be unguessable by an attacker. In any case, a random full-length (i.e. one whole cipher block) IV should generally always be safe. You might also want to consider using SIV mode (RFC 5297), which offers resistance against accidental IV reuse. – Ilmari Karonen Jan 10 at 20:11
1  
I'm... not sure I've entirely understood the scenario you describe. In any case, with just one user and one password, the only effect salting has is to prevent attackers from precompiling any tables (rainbow or otherwise) to speed up their attack before they've actually seen the hash. While this is useful enough in itself, the main benefits of salting come when there are multiple users, since having a separate salt for each user (or message) prevents an attacker from reusing the same KDF calculation to test the same password against multiple users. – Ilmari Karonen Jan 10 at 20:48
1  
In any case, IVs don't really have any effect on brute-force password guessing attacks like this; the kind of attacks prevented by proper IV usage are plaintext-recovery (not key-recovery) attacks based on reusing the same key and IV to encrypt multiple message, which can leak information about the plaintexts for those messages. – Ilmari Karonen Jan 10 at 20:52

In Password-Based Encryption (PBE) we use a randomly generated (and hopefully unique) salt to prevent dictionary attacks on the key generated from a password. Every "user" in a system should at least have a different salt.

Since key derivations can be made arbitrarily hard just by increasing the iteration count, we can have, let's say, a key derivation that lasts 5 seconds on the sender machine. If you would always generate a fresh salt and derive the encryption key for every message of your hypothetical chat protocol, then this would be very frustrating for your users, because a 10 second delay for every message (PBKDF at sender and receiver side) is not that great.

You still need to randomize every single message, so you can claim CPA-security. You can do that by using a "long-term" random salt and a fresh IV for each new message. This will incur only the previously mentioned delay for the first message and be otherwise very fast for the rest of the communication.

Of course, if you don't need low latency messages, then you can simply set the IV to some fixed value for each message and derive the encryption key with a fresh new salt each time. Then you don't need to sent the fixed IV value along with the ciphertext anymore. This is at least CPA-secure as long as the block cipher is good.

Using a random IV in addition to a random salt for each message is a little bit wasteful, but not necessarily bad.

share|improve this answer
    
Thanks a lot guys, you both cleared it up a lot, but I got the same thing if you can confirm please... I would like to mention that I am referring to single salt for user and different IV for each message, if there is no issue. Supposing some unauthorised party gets a hold of my encrypted message with no salt but unique IV he still cannot use rainbow tables and has to check against all possible passwords with the IV in that message. Continued in next comment..... – Kaustubh Jan 10 at 20:02
    
So now brute-forcing with the IV in message he can find the message and the password in just one round of brute force. Whereas if I used a salt to which took a really resource intensive KDF, it would take him a really long time to brute force the possible password with the salt.... So I suppose it is impractical to use both randomly generated salt and IV both.... right .. ? Thanks!! – Kaustubh Jan 10 at 20:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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