# Is XOR in a CBC-like mode secure?

Assuming that $K_{n}$, $P_{n}$, and $C_{n}$ are individual bytes of the key, plaintext, and ciphertext respectively.

The first byte of ciphertext is computed like this:

$C_{1} = K_{1} \oplus P_{1}$

And the rest of the bytes are computed like this:

$C_{i} = K_{i} \oplus P_{i} \oplus P_{i-1}$

Is this a good way of encrypting data, or is there some loophole that I've overlooked?

-
Hello, welcome to crypto; I edited your title to be a little more descriptive (I realise you probably didn't know what to put as the title :)) - if you want to improve it, or roll it back, there is an edit link directly underneath your question which you can use at any time :) –  Ninefingers May 12 '12 at 19:59
Thanks, Ninefingers! You're right, I had no idea what to put as the title. –  Jack V. May 12 '12 at 20:27
One could name this mode PBC (plaintext block chaining). But as each block gets encrypted with a different key, this isn't really a block cipher mode. –  Paŭlo Ebermann May 12 '12 at 22:31

Well, that transform can be viewed as an unkeyed transform of the plaintext, followed by exclusive-or'ing the key. It would also appear to have the same limitations as the usual key exclusive-or; how it works out depends on the details of the key:

1. If the key is as long as the plaintext, and is chosen at random, this is effectively a One Time Pad, with a same protections and drawbacks; it is perfectly secure such if you use a key once; however, if you ever use it again to encrypt a different message, it is possible (and usually: likely) that someone can recover both messages.

2. If the key is shorter than the plaintext, and when you run out of key, you start back at the beginning; well, you've got a variation on the Vigenère cipher, and it can be attacked in a similar manner. The extra unkeyed transform you put on the plaintext may complicate a ciphertext-only attack a bit, but I wouldn't count on that slowing down a knowledgable attacker a great deal.

3. If you generate the key dynamically via a key stream generator, then you've effectively got a Stream Cipher; if the key stream is indistinguishable from random, then you're good; if not, well, there may be weaknesses.

-
Yes, the title was edited by Ninefingers, and the reason I don't use the ciphertext to encode more ciphertext is that would seem insecure, because the previous byte of ciphertext is known to a possible attacker, while the previous byte of plaintext is encrypted. –  Jack V. May 12 '12 at 21:14
@JackV.: fair enough; I editted out the 'this doesn't look like CBC mode' comment out from my reply. –  poncho May 12 '12 at 21:18
I went for CBC-like as that's the best I could explain it, as opposed to just "this algorithm", but feel free to improve, anyone. If I can come up with a better one, I will, when it's not so late :) –  Ninefingers May 12 '12 at 21:40
The idea I had for the key is that the user provides a key of n-bytes, then the plaintext is divided into n-byte blocks, padded if necessary, and then for each block, you run the algorithm. –  Jack V. May 12 '12 at 21:43
Yes, if the message is longer than N bytes, it is insecure. The exclusive-or of two different ciphertext blocks will cancel out the key; leaving you with (after undoing the unkeyed plaintext transform) the two plaintext blocks exclusive-or'ed together; that's known to be weak. –  poncho May 13 '12 at 1:40