

#1




Hi reteam,
I've read XOR encryption is very susceptible to crypto analysis attacks where the key length is less than the length of the plaintext. Also XORing multiple keys of lengths divisible by each other does not increase security, eg: XORing the plaintext with a key of length 4 bytes and then XORing the plaintext with a key of 8 bytes is no more secure than simply XORing the plaintext with only an 8 byte key. But what if I used keys with lengths of prime numbers, and I apply them in the same manner as above, ie one after the other to the plain text? For example given four keys of lengths 7, 19, 23 and 29 bytes respectively, if I XOR each of these keys one at a time across the plaintext, does this give me an effective key length of 17*19*23*29 = 215441 bytes because these key lengths are all prime? Would the key still be susceptible to crypto analysis attacks if I had used a plaintext length matching that effective key length (in this example 215441 bytes) ? 
#2




any ideas? anyone?

#3




The simple answer is yes, absolutely vulnerable. XOR encryption with any repeats is kidsister protection at most. The repetition of each subkey will be seen in the crypted document, even if the plaintext doesn't happen to have big blocks of zeros (like most EXEs do). If the cryptanalyst can get (or guess) a copy (even a partial copy) of the plaintext which you have crypted, it is almost trivial to recover all of the subkeys you used to build your rolling key. If not, standard statistical analysis will still show the patterns, and then it's just a superhard cryptoquote puzzle.
Consider shuffling & altering the characters in your keys in a nonlinear way every so often. Use different shuffle functions on each subkey. That will buy you quite a bit more strength, as long as the attacker doesn't have knowledge of your algorithms. Still not anything near NSA level, though. Khan's classic The Code Breakers is probably the best reference on attacks on older, simpler crypto like XOR schemes. Published in 1967 but still relevant. 517A5D out. 
#4




thanks 0x517A5D!! 