On Sep 17, 2013, at 11:54 AM, "Perry E. Metzger" <[email protected]> wrote:
> I'd like to note quite strongly that (with certain exceptions like
> RC4) the odds of wholesale failures in ciphers seem rather small
> compared to the odds of systems problems like bad random number
> generators, sabotaged accelerator hardware, stolen keys, etc., and a
> smart attacker goes for the points of weakness....
Actually, I think there is a potentially interesting issue here: RC4 is faster
and requires significantly fewer resources than modern block ciphers. As a
result, people would really like to use it - and actually they *will* continue
to use it even in the face of the known attacks (which, *so far*, are hardly
fatal except in specialized settings).
So ... is there some simple way of combining RC4 with *something* that
maintains the performance while retaining the speed? How about two separate
RC4's (with independent keys) XOR'ed together? That would still be
considerably faster than AES.
There appear to be two general classes of known attacks:
1. The initial key setup doesn't produce enough randomness;
2. There are long-term biases in the output bytes.
The first of these can be eliminated by using AES to generate values to
scramble the internal state. The second can be hidden by doing post-whitening,
XOR'ing in a byte from AES in (say) counter mode. If you use a given byte 64
times, then use the next byte of the output, you pay 1/64 the cost of actually
using AES in counter mode, but any bias in the output would have to play out
over a 64-byte segment. (Actually, if you use ideas from other stream ciphers,
changing the whitening every 64 bytes probably isn't right - you want the
attacker to have to guess where the changeovers take place. There are many
ways to do that.)
Of course, don't take any of the above and go build code. It's just
speculation and likely has serious problems. I toss it out to illustrate the
idea. Whether it's actually worthwhile ... I doubt it, but it's worth thinking
about.
-- Jerry
_______________________________________________
The cryptography mailing list
[email protected]
http://www.metzdowd.com/mailman/listinfo/cryptography
