5 ms·

This is a classic stream cipher. A stream of bits is generated and xored with the plaintext. In code size RC4 is of very similar size, but work on bytes rather

This is a classic stream cipher. A stream of bits is generated and xored with the plaintext. In code size RC4 is of very similar size, but work on bytes rather than 32 bit words. RC4 has been used in a wide number of areas, like SSL/TLS. It is now known to have problems, but it was belived to be secure for many years, but now some quite bad attacks are known (and much harder to break than this algorithm) I see one very big problem with the algorithm. If I know the first bytes encrypted (a known plaintext attack), I will recover the xor of two parts of the raw key. On the next word encrypted, it will be a shifted version of the raw key material. This will eventually mix, but the mixing is slow enough that the key can be recovered. Even ciphertext only attacks will be possible if you know or guess underlying statistical properties of the plaintext, like that this is english text, HTTP headers or whatever. In general, too much of the key material leak into the keystream, making the cipher breakable. In practice, the length of an HTTP header will likely leak enough of material to break it. A better streamcipher would have a key schedule before the encryption, making a table of bits that are mangled based on the key bits so that there is less correlation between the keystream and the key instead of using the key directly. Any such correlation will make the cipher breakable. Furthermore, there must be more mixing of bits than the given algorithm has. RC4 appear to have no more mixing, but that uses a much bigger table of 256 bytes, and not only the size of the key like this one, that makes it very likely that a byte has been mixed quite a lot the next time it is used.

quelsolaar 13y ago
"I will recover the xor of two parts of the raw key." Yes, but how is this useful since the relationship between these two are no longer valid before the next operation? the shift is slow, but the XOR destroying one of the two components that have a known relationship is instant.
- alephnil 13y ago
  They are extremely important because you can use it to construct an attack that let you narrow down the number of guesses you have to do to recover the original key, so that it becomes feasible to crack the code. In general, leaking information about the key like this is almost a cardinal sin in cipher design, as it will give an opportunity for an attack. Modern ciphers will leak practically no information about the key.
  - quelsolaar 13y ago
    True, if you want to brute force the algorithem you loose some bits by knowing that somewhere in the key there are 2 values that together become an xor. The question for me is if this information compounds over time. My thought was that it wouldnt since the key is modified.

quelsolaar 13y ago

"I will recover the xor of two parts of the raw key." Yes, but how is this useful since the relationship between these two are no longer valid before the next operation? the shift is slow, but the XOR destroying one of the two components that have a known relationship is instant.

alephnil 13y ago
They are extremely important because you can use it to construct an attack that let you narrow down the number of guesses you have to do to recover the original key, so that it becomes feasible to crack the code. In general, leaking information about the key like this is almost a cardinal sin in cipher design, as it will give an opportunity for an attack. Modern ciphers will leak practically no information about the key.
- quelsolaar 13y ago
  True, if you want to brute force the algorithem you loose some bits by knowing that somewhere in the key there are 2 values that together become an xor. The question for me is if this information compounds over time. My thought was that it wouldnt since the key is modified.