[Cryptography] RC4 again (actual security, scalability and other discussion)

Lodewijk andré de la porte l at odewijk.nl
Sun Mar 9 15:57:27 EDT 2014


2014-03-09 4:30 GMT+01:00 Bill Cox <waywardgeek at gmail.com>:

> The recent attacks on RC4 scare me a lot more than these efforts to
> detect what algorithm generated the data stream.  It' not a complete
> attack yet, and ARC4 remains secure currently for many applications,
> but now I am concerned that ARC4 may be actually broken in the not too
> distant future, and that it may already be broken in government crypto
> agencies.  Of course, academics will cringe at my use of the the
> phrase broken, since many feel an encryption algorithm is broken once
> it's output can be detected as non-random.  That's just nonsense.  An
> algorithm is only broken when an attacker can decrypt stuff.
>

Being able to detect a specific pattern is just another way of saying
"There's something obviously going on here, we can see it, but we don't
really know what yet". Cryptographic output is supposed to be homogeneous,
random, noise. If it's so wrong that you can see which crypto it is, stop
using it. There's something wrong. There's patterns that shouldn't be
there. This is "funny engine noises". Stop using it.

Else just take some sort of streaming xDES or something. Pretty sure enough
rounds would still work just fine and dandy.

Hell, why not just use some pre-DES standard. Hardly any people out there
would know how to use Differential Cryptanalysis. Since nobody will ever
manage to break in it's secure. Of course, engineers will cringe at my use
of the the phrase secure, since many feel a system is insecure once it has
a known attack against it.  That's just nonsense.  A system is only
insecure when an attacker actually breaks in.

p.s. double spaces are a bad substitute for clear writing. Comma count is a
side channel for simplicity is a side channel for clarity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140309/106cd084/attachment.html>


More information about the cryptography mailing list