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 FrameSep 14 '13 at 20:53

1 Answer
1

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.