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

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?

share|improve this question
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 :) – Antony Vennard 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

1 Answer

up vote 4 down vote accepted

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.

share|improve this answer
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 :) – Antony Vennard 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
show 1 more comment

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.