9

Are there any known attacks against RC4 if used with a single-use, random-generated 32-byte key, and 3072 random bytes prepended to the plaintext?

Are there any reasons why we should consider such a use of RC4 less secure than an other state-of-the-art stream cipher with a single-use, random-generated 32-byte key?

pts
  • 223
  • 1
  • 8

2 Answers2

21

Yes, there are reasons to avoid RC4 and to consider it hopelessly insecure.

The single-byte biases—the biases that were so obvious that Bob Jenkins found them empirically on his 1994-era laptop within days of RC4's publication—may decay as you go down the keystream. But these are the tip of the iceberg. Many other detectable multi-byte biases have been identified that continue long into the keystream, notably in Fluhrer–McGrew 2000 and Fluhrer–Mantin–Shamir 2001, and applied in practice on TLS and WPA year after year after year.

The only reason academics chose to spend precious grant money on designing and implementing public attacks on RC4 is that people kept using it in important protocols against the advice of cryptographers for twenty years after it was broken.

That nobody has broken your protocol with RC4 probably just means your protocol isn't as important as TLS and WPA.

Just Say No to RC4, kids!

Squeamish Ossifrage
  • 49,816
  • 3
  • 122
  • 230
7

Unfortunately, most of them. The issue here is the notion of "single use". You have to consider that a single encryption session might be longer than your random 3072 prepended bytes. So RC4 output bytes 3073 onward will be (presumably) XORed with the genuine plain text. If you then aim to encrypt 1GB of hospital patient records including weeping diseases, HIV status and religion, all the many identified long run biases will bite you hard. Initial byte drop won't help other than to reduce the most extreme biases. The other still very strong biases will be there downstream.

You might also fall foul of a weak key state if the keys are random or perhaps lacking sufficient entropy. They exist. There are so many short and long run biases that it's just simpler to refer you back to the Q&As tagged with RC4. Are there any long term RC4 bias based exploits? is just a single example. And of course no (Does this fix)RC4 answer is complete without Why is writing your own encryption discouraged?

Yes, RC4's problems are well understood, but if you review the RC4 answers you'll see that RC4 is fundamentally broken and so far no tweak has managed to restore faith in it. To quote someone earlier, "Just Say No to RC".

Paul Uszak
  • 15,905
  • 2
  • 32
  • 83