# Is it dangerous to use plaintext as IV in CBC?

Is it dangerous to use plaintext as IV in CBC?

For example: I want to encrypt $p1$, $p2$ with CBC. However I use $p2$ as the IV for CBC purposes.

What would be the risk of not using a IV based on random number(s)?

-
Your "specification" is pretty unclear. How would you use the plaintext as IV? If you use the plaintext as IV, you need to tell the decrypter about it, but since the usual goal is the keep the plaintext secret, that doesn't make sense. – CodesInChaos Sep 14 '13 at 11:40
CBC IV should either be random or an encrypted nonce. Using P2 as IV to encrypt PT results in an all 0-bit input to the block cipher, in addition to leaking the first plaintext block. – Richie Frame Sep 14 '13 at 20:53

As already given as partial answer in the comments, you would have to leak the second block as an IV is normally transmitted without confidentiality. You could of course retrieve it from initially decrypting the ciphertext without IV, and retrieve the first block value later on. But using an encrypted IV has got it's own vulnerabilities.

The other issue is that the IV in CBC is XOR'ed with the first block of the plaintext. Now an attacker can look at previously transmitted (initial) ciphertext blocks and see if it matches the one it is currently investigated. If they match then it knows that the result of XOR'ing the IV and plaintext matches a previous combination. This means that IV ^ P1 == IV' ^ P1'. As IV and IV' are known, this leaves you with an equation with just two variables. If more identical ciphertext blocks are found, the amount of information about the first block of plaintext increases.

There are other issues as well. You require at least two plain text blocks for your algorithm to use for instance. If there is a repeat of the first two blocks, then you will end up with an encryption of just zero's, and block 3 will become vulnerable as well.

Now it may be that your protocol is secure against these attacks, but you are using CBC without it's preconditions being satisfied, so you should then prove security of your protocol yourself.

In general, this scheme is not a good idea. It's pretty close to using a static IV instead of one that is indistinguishable from random by an attacker.

-
Anything missing from my answer, Tony? – Maarten Bodewes Sep 18 '13 at 15:36
Guess he's one of those never-to-be-seen-again acounts, which is a shame as your answer is great and it would deserve an accept. (Just my 2 cents.) – e-sushi Oct 27 '13 at 20:44
@e-sushi compared to stackoverflow, crypto is a breeze of fresh air - and who knows maybe life was happening to him... – Maarten Bodewes Oct 27 '13 at 23:03
That's true… forgot about the RealLife™ factor. Probably been looking at SO too much lately. ;) – e-sushi Oct 28 '13 at 13:46