Tell me more ×
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.
up vote 3 down vote favorite
2

The initialization vector (IV) is exclusive or'd against the plain text before encryption for the first block sent in order to prevent an attacker from learning that duplicate message blocks are being sent. This technique is often used with streaming modes like CBC.

I have researched some of the questions that were asked about whether it was safe to pass the IV in the clear. The general consensus seems to be that the IV can be safely passed in the clear, but the IV should be random to prevent certain kinds of attacks. Using a counter for the IV is also thought to be vulnerable as well and only randomly generated IVs should be used. I don't really understand this since the reason stated for passing a random IV is that it can not be easily guessed.

In any case, my question is as follows:

It should be relatively easy to send the first block of a message encrypted, but without any IV processing. This first block could contain the IV which would then be used for all remaining blocks of the message. Since the IV in the encrypted message is random, there should never be any duplicate first blocks. How come this is not being done and isn't it at least a little safer than sending the IV in the clear?

share|improve this question
It would, but it's a great question that may prevent programmers from creating critical security vulnerabilities. +1 – Adam Liss Apr 4 '12 at 22:36
Note that what you propose comes down to prepending the IV to the plain text, and then encrypt the plain text with a zero'ed out IV. That is, at least for CBC mode encryption. – owlstead Apr 5 '12 at 1:04
"Note that what you propose comes down to prepending the IV to the plain text, and then encrypt the plain text with a zero'ed out IV. That is, at least for CBC mode encryption " - Well, sort of. It simply won't do an xor at all for the first block which contains the IV. But as I said in the question, that should not be a problem since the IV will be completely random. If you see a problem with this, then can you please elaborate – Bob Bryan Apr 5 '12 at 6:48
The IV requirements are different for different encryption modes. CBC should generally use a cryptographically random IV, but CTR mode only requires uniqueness, so a simple counter can be used. – Stephen Touset Nov 30 '12 at 21:09

migrated from stackoverflow.com Apr 5 '12 at 5:48

3 Answers

up vote 8 down vote accepted

Depending on the mode of operation, transmitting the IV encrypted (with the same key as used for the rest of the process) can actually weaken security a lot.

For example, in the CFB and OFB modes, the IV is encrypted and the result XORed with the first block of the plaintext to produce the first block of ciphertext. Thus, an adversary who knows the encrypted IV can trivially undo the XOR to recover the first block of plaintext! The same is true for the CTR mode, if the IV/nonce is used directly as the initial counter value.

The CBC mode works differently, and does not break as catastrophically if you encrypt the IV before transmitting it. However, as Henrick Hellström has pointed out, knowing the encrypted IV still lets an adversary figure out whether the first block of the plaintext consists of all zeros.

share|improve this answer
up vote 4 down vote

IV is called an initialization vector because it is the first vector. The next vectors are the cipher text blocks. And guess what: all of them are send in plain. So what again are you trying to achieve by simply encrypting the very first one?

Answer only valid for particular blockcipher encryption modes (most importantly CBC of course).

[edit]

After successful completion of the Coursera course "Cryptography I" by Dan Boneh from Stanford university I can certainly tell that encrypting the IV with the same key is a very bad idea. If you do want to encrypt, e.g. because the IV is not fully random, please use a second key.

share|improve this answer
Ok... Good point. The previous crypted data block that was sent is used as the next IV for decrypting. I guess in answer to your question, it is a matter of philosophy. If I have a choice between giving a potential attacker something to chew on, like a plaintext IV, or nothing at all like an encrypted IV, then I prefer to give him nothing at all. I would also point out that it is tough to predict the future. No one really knows what advances there will be in breaking encryption schemes in the future. A plaintext IV may be just enough to help an attacker to break in some day... – Bob Bryan Apr 5 '12 at 2:01
2  
@BobBryan: Owlstead is right, so please consider the implications. If sending a plain text IV would in any way pose a security threat, clearly using CBC mode in the first place would be at least as bad. Conversely, encrypting the IV (using the same key as you use for the bulk of data) might actually introduce vulnerabilities of its own, in particular if the first block of plain text contains 16 zero valued octets. – Henrick Hellström Apr 5 '12 at 7:51
You are right Henrick. The IV is sent in the clear since it is the encrypted bytes of the last block that is used as the next IV. I think that this is unwise and potentially vulnerable in the future even if no one can positively state today that there is a vulnerability with this approach. I have an idea for a new mode that would use an IV that would not need to be sent at all. Actually, it would be 2 new modes. One for streaming messages that are sent sequentially and another mode for messages that are intermittent in nature. I will post a link back when I have published them. – Bob Bryan Apr 5 '12 at 17:07
"I think there might be some weakness somewhere that I can't put my finger on in an encryption mode that's been widely studied, analyzed, and deemed secure by experts. So I'm going to make a bunch of changes." Sounds sensible to me. – David Schwartz Apr 9 '12 at 4:59
@BobBryan you are missing the point, if I'm an attacker, and I have an magic attack that is based on knowing the IV, and you have magically encrypted the IV (Block 0) so that I can't use it in my attack, you have only thwarted me from decrypting Block 1 of your plain text, because every other block N used the Block N-1's cipher text as the IV and you didn't magically encrypt those IV's as well. – jbtule Apr 25 '12 at 15:18
up vote 0 down vote

In general, encryption is computationally expensive, while the exclusive-or operation is so cheap as to be negligible. Encrypting a random IV would be more expensive than XORing it with the first message block, with no cryptographic advantage.

As you said, the purpose of the IV is to prevent replay-type attacks, which would allow an attacker to recognize repeated blocks and eventually determine the key. But the IV needn't be secret as long as it's unique and can't be predicted. Giving the IV to an attacker along with the ciphertext will provide no cryptographic advantage.

On the other hand, block encryption can be done in "counter" (CTR) mode. This does allow the sender to use sequential initializers, but they're combined with a nonce that's never re-used with the same key.

share|improve this answer
1  
NONCE, generally the correct nomenclature for the counter in the counter mode is NONCE, not IV (although many frameworks use the name IV as the purpose and format are closely related) – owlstead Apr 5 '12 at 1:00
It is true that encrypting the IV takes longer. I am planning on writing an article that I'm hoping to publish either in a magazine or on my blog that benchmarks how fast symmetric encryption is with Microsoft classes in the .NET framework as well as some techniques that can be employed to dramatically improve perforance by at least 2.5 times, which is from results that I have already observed. Based upon my results, block encryption of 16 bytes with a 128 bit key can be done on my i7-950 machine roughly 2.5 million times per second using single threaded C# code. – Bob Bryan Apr 5 '12 at 2:28
"It's a common error to use the same key to encrypt both the IV and the message, but this should never be done because it allows an attacker to "undo" the randomness that's supposed to be created by the IV." Are you talking about counter mode here? I was not aware that encryption of the counter should be used with a different key than the plaintext. Do you have any links that provide more details about this? Right now, I don't understand how a message with a counter could be broken more easily by using the same key as the rest of the message. – Bob Bryan Apr 5 '12 at 2:35
Sorry for the confusion - the requirement that the IV be encrypted with a different key applies to CBC, not CTR (which uses a nonce in addition to a counter). With CBC, if an attacker issues an all-zeroes message in a chosen plaintext attack, the first encrypted block is simply the encryption of the IV, which provides enough information to break semantic security. I've edited my answer accordingly; thanks for the catch! – Adam Liss Apr 5 '12 at 2:53
2  
@Adam: To be complete, if the IV is unpredictably random then it does not need to be encrypted to achieve semantic security. – B-Con Apr 5 '12 at 18:18

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.