A modification of the Vigenère Square encryption algorithm
In it's simplest form, the Vigenère Stream uses the previous letter to define the alphabet to be used to encode the current letter. Lets take the old "If cryptography is outlawed, only outlaws will have privacy" quote for our example.
The letter preceding the O in "only" is the D in "outlawed."
O in the D alphabet is R. We would then use the R alphabet to encode the N in "only." N in the R alphabet is E. L in the E alphabet is P. Y in the P alphabet is N, and so forth. The final pithy saying is "If cryptography is outlawed, repn bvozzvn ltep wwrv kbjeege." If you were encrypting something from the beginning you would simply leave the first letter as is.
The most obvious flaw in the simplest form is that every occurrence of the letter A results in a couplet of the same letter. Furthermore if the attacker knows you're using the Vigenère Stream ((s)he/it) can begin decryption at any point in the message. This can be corrected for by increasing the offset, I.E. using the letter N spaces previous to define the alphabet used for the current encoding. If we have an offset of 2, for example, we would use the E in "outlawed" to encode the O in "only", D to encode the N, and so forth as usual. (Incidentally, with an offset of 2 the message becomes "If cryptography is outlawed, sqdo riktkpc lkwv dvyz nqvlvnt"). Offset will obscure the pairs of letters that represent A and it's encoding alphabet (A always encodes the the letter of its encoding alphabet) and make the offset less trivial to guess. A high enough offset should reduce the "A couplet" effect to noise and the encoded text will appear as random gibberish.
The problem with large offsets is that the characters at the beginning of a message won't have "previous letters" to define their encoding alphabet. An attacker merely has to count up to the point where the encoding begins to find the upper limit of the possible offset (or if you wanted to encode from the very beginning of the message, this would find the actual offset). The stretch of unencrypted text can be eliminated by prefacing the block of cipher text with a sufficient block of plain text to provide for the offset, or by using keys. In fact, there is no difference between the two methods... in the former case the block of plaintext simply IS your key. Stated another way, "repn bvozzvn ltep wwrv kbjeege" is "only outlaws will have privacy" with an offset of 1 and D as a key; "sqdo riktkpc lkwv dvyz nqvlvnt" is the same message with an offset of 2 and the key ED. A simple Vigenère Stream encoded from the beginning is an offset of one with A as the key. Or you could pick a key at random to encrypt this beginning stretch of ciphertext... repeating it to fill the offset and then cutting it off when the offset encounters the beginning of the encrypted text.
This talk of keys brings us around to the real purpose of the Vigenère Stream. The methods involved in breaking the Vigenère Square depend heavily on the text following normal grammatical and letter frequency conventions and to be encrypted with a short key. The traditional method for increasing the security of the Vigenère Square was to have longer keys. A message encrypted with a key that was the same length as the message supposedly cannot be broken by any method other than brute forcing it. The trouble is, of course, that it's fairly hard to inconspicuously share large keys and to keep them secret. The Vigenère Stream has the basic effect of encrypting the message while generating the key on the fly. The weakness of the Vigenère Stream alone is, of course, that the ciphertext essentially becomes the key... all you have to do is find the offset within the text and you can begin decryption. BUT! if you use the regular Vigenère Square algorithm, even with a relatively small key (perhaps the same one you use to encode the offset text), on the output of the Vigenère Stream the usual analyses will not work and your key will have to be brute forced
Sat Jun 22 2002 at 00:19:15
would like to state: 'this method is woefully insecure
[...] "Do not use this under any circumstance
", because weak crypto is worse than no crypto
To Reply: What in the devil could possibly be insecure about an encryption algorithm where the ciphertext is its own key? ¦¬)