7
$\begingroup$

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?

$\endgroup$
  • 4
    $\begingroup$ Is there a specific reason forcing you to use RC4? If not, why bother using a cipher that is broken (even though maybe not in this constrained scenario), when you might as well use another secure stream-cipher eg AES-CTR or ChaCha and not have to worry? $\endgroup$ – SEJPM May 24 '18 at 14:13
  • $\begingroup$ @SEJPM: RC4 is simple to implement, and its problems are well researched and understood. $\endgroup$ – pts May 24 '18 at 15:10
  • 5
    $\begingroup$ ChaCha is simple to implement, and it is well-researched, and it doesn't have problems. $\endgroup$ – Squeamish Ossifrage May 24 '18 at 15:30
  • 3
    $\begingroup$ Why do you want to prepend 3072 random bytes? Just generate the 3072 bytes from the keystream and throw them away. That's a common way of hardening RC4, has the same security as your proposal, but is easier to implement and doesn't need so much random entropy to send a text. $\endgroup$ – Nova May 24 '18 at 16:15
  • 1
    $\begingroup$ Chances are good that there are algorithm implementations available to you that are at the same time faster and more secure. And if not faster then still fast and more secure. Also, you can substitute "more secure" with "actually secure" in the statements above because you can believe the people who tell you RC4 is unsafe. (Also RC4 is really slow compared to modern algorithms on modern PCs, servers, and smart-phones.) $\endgroup$ – Future Security May 24 '18 at 17:16
17
$\begingroup$

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!

$\endgroup$
5
$\begingroup$

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".

$\endgroup$
  • $\begingroup$ Thank you for the informative answer! Unfortunately I'm not able to accept both answers. $\endgroup$ – pts May 24 '18 at 17:45
  • $\begingroup$ While I don't disagree with the advice to avoid RC4, what biases in a single encryption of a gigabyte database of hospital records could possibly reveal any information? These are often multi-byte biases that require many encryptions with different keys to become obvious. $\endgroup$ – forest May 25 '18 at 4:59
  • $\begingroup$ @forest I actually agree with you about this aspect of RC4. I'm a great fan of RC4 and use it for some stuff myself. It fits perfectly with a Pearson hash as the key scheduler giving a possible 1684 bit seed. And of course MS CryptGenRandom uses RC4. I too think that it would be unlikely to leak, but I chose the hospital records example for a reason. This thinking is considered taboo. A lot of crypto is built on trust, and you can see the community' sentiment in Squeamish's answer. If you consider the bigger picture, HIV status + self tweaked RC4 = worried Information Commissioner. $\endgroup$ – Paul Uszak May 25 '18 at 12:01
  • $\begingroup$ @PaulUszak Microsoft's CryptGenRandom has used NIST-standard AES_CTR_DRBG since Vista/2008, while XP/2003 used SHA-1 in counter mode as described in FIPS 186-2. If Windows did in fact once use RC4 for CryptGenRandom, it was a long time ago. Source: msdn.microsoft.com/en-us/library/windows/desktop/… $\endgroup$ – rmalayter Jun 1 '18 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.