# Is it possible to deduce the IV from CBC ciphered data, without knowing the key?

The question came up here, which left me thinking:

Is it possible to deduce the IV from CBC ciphered data, without knowing the key? And if not, why is it considered a bad idea to create an IV by, for example, filename$\oplus$Key, if you never store the IV?

I know, that XOR is a no-go, when you are using ciphers, because, XOR is bidirectional. Having the filename and the IV will give me the key. But HOW will you get the IV from CBC ciphered data without having the key first?

• The standard thing is to simply send the IV with the ciphertext. I think you need to do some basic reading on the issue though to understand the difference between a block cipher (eg AES) and a modes-of-operation such as CBC-mode. A block cipher doesn't use an IV, the mode does. – Cryptographeur Apr 8 '14 at 17:58
• I know, that there is a difference, thats why i am not using ECB with Rijndael. I just forgot to mention it in the question. What about my question thoug? Is it possible? – Andreas Apr 8 '14 at 18:25
• What I'm trying to tell you is that it's nothing to do with Rijndael at all. Your question is actually about CBC and nothing else. Given you hadn't specified CBC until this edit that meant your question wasn't answerable. When people use CBC, the standard thing to do is to transmit the IV along with the ciphertext – Cryptographeur Apr 8 '14 at 18:28
• Okay, but in my specific case, i am using Rijndael with CBC and i don't care, whether it is common practice to ship the IV. If the IV is not the secret, I can also create it, from XOR, or always use Zeros. Am I correct in that assumtion? Given, that I do not ship the IV. – Andreas Apr 8 '14 at 18:32
• @Andreas: No you can't use all zero, because CBC requires an unpredictable IV – Cryptographeur Apr 8 '14 at 18:51

For CBC mode, the IV must be

1. Never used twice with the same key
2. Unpredictable

So, in your example (filename$\oplus$key), if you ever encrypt two files that have the same filename with the same key, you will violate #1.

Now, you may be tempted to say "but I always generate a new key for every file that I encrypt, so that example doesn't apply". Fine, it doesn't. There are probably some use cases where filename$\oplus$key is fine. But, there are a lot of use cases where this will have big problems. In crypto, we typically try to develop our systems so that they are secure no matter how they are used. This is often not entirely possible, but that is what we aim for. So instead, we would generate a random IV and publish it with the ciphertext.

To give you an example of where filename$\oplus$key could have issues, consider the following. What if you publish your IV (which is a very, very common practice). Then all I have to do is brute force the file name and I have the key.

• I am tempted to say: "But there can not be two files, with the same name, because the name has to be unique" :) But i am using the same Key for all. I understand, that my little excursion might break rules when using it as a general system. But I do not want to create a new general lib like OpenSSL. This is for a single purpose and "not two files with the same name" is a precondition to all of it. – Andreas Apr 8 '14 at 19:20
• I cannot get why it must to be unpredictable. Are there any weakness known? – ddddavidee Apr 9 '14 at 8:25
• @ddddavidee I was going to suggest you post that as a question on here, but I found the question & answer on stack overflow (stackoverflow.com/questions/3008139/…). – mikeazo Apr 9 '14 at 11:41
• @mikeazo: I was looking for a link for that last night. Are we not allowed to dupe SO on such a fundamental question? :P – Cryptographeur Apr 9 '14 at 23:03
• @figlesquidge I think it is fine. Ideally questions like that would have been migrated here, but I don't think this site was up yet. It would be a good question for our site. Someone could always post a similar question here. – mikeazo Apr 10 '14 at 0:17