I want to encrypt my network communications with RC4. The reason for choosing RC4 is the simple implementation and speed.

I need to have a pure Python implementation, because I cannot compile for my target system. My implementation is slightly modified from TLS Lite.

If I understand the security issues correctly, the main problem is that the algorithm is not designed to be used with a nonce. As proposed at Wikipedia, my approach is to generate an MD5 hash of the key and a nonce and use this as encryption key.

Is this enough or do I have to implement the dropN variant, too? Any other weak spot I have to look at?

2 Answers
2

First: Do NOT use MD5. Ever. Never. Especially not in any form of security contexts. Use at least SHA-1 or SHA-2 (256 or 512/256 if speed is an issue on 64-bit machines). Apart from some legacy reasons, MD5 should be banned and the faster you stop using it the better you are off.

I took a look at your implementation and it looks like a clean, simple implementation. I would suggesrt adding some KATS from RFC 6229 to show that it works. And some documentation.
–
Joachim StrömbergsonJun 20 '12 at 8:30

Regarding md5 in SSLv3 you can disable these suites in your broswer. I would assume Mozilla knows about the status of md5, but includes it due to legacy support reasons.
–
Joachim StrömbergsonJun 20 '12 at 8:32

It has no Initialization Vector distinct from the key. If you use the same key twice, then you get twice the same sequence of pseudo-random bytes, and using that is a deadly sin. Thus, each key should be used only once (for a possibly long stream of bytes). Deriving the encryption key from a "master key" and a per-message random value, using a key derivation function (e.g. a hash function), can correct that if done properly.

It has rather big biases in the first bytes. Dropping the first N bytes of output (for some value of N which should be a few hundreds) can fix that.

It has small biases afterwards. These can be statistically exhibited over a few gigabytes of data. There is no known cure. These biases are rarely fatal.

RC4 is encryption only. It does nothing for integrity. In any serious attack model, encryption must be coupled with a MAC. Combining a symmetric cipher and a MAC securely is not easy.

For all these reasons, the best way to use RC4 is often not to use it at all. Instead, use an authenticated encryption mode which does all the hard work; my favourite is EAX.

As for performance, consider that modern x86 CPU offer an hardware implementation of AES against which RC4 will be an arthritic snail. If you nonetheless have an actual performance issue on an architecture which does not offer an hardware-optimized AES, then RC4 is not the best in class either; there are other stream ciphers which are both faster and more secure (all the stream ciphers from the current eSTREAM portfolio received a fair amount of scrutiny and went through unscathed).

To be fair, ECRYPT says that it is just a bit too early to recommend the algorithms in the eSTREAM portfolio for general usage. They also say that the algorithms raise interest, have received and keep on receiving scrutiny, and that some have probably already been deployed in production by early adopters. My rule of thumb is to wait 5 years between publication and usage; the portfolio has been finalized in 2008 and we are now in 2013, so the algorithms are becoming "ripe" (at least in my own, necessarily subjective view).
–
Thomas PorninJan 7 '13 at 12:10