At 10:49 AM -0400 7/28/99, Arnold G. Reinhold wrote:
I believe the input mechanism Anonymous described *is* the RC4 key setup
mechanism. In any case, I take Anonymous' remarks about the brittle nature
of RC4 very seriously. I wouldn't mess with it just to double the entropy
pool. If you think more entropy is needed, build a side buffer or run two
copies of RC4.
It doesn't double the entropy pool. It increases it from being order 256!
to being order 512!. Incidentally, the remarks about brittleness apply just
as much to a variant that is 9 bits wide as well as 8 bits wide. There are
certain states you don't want it to be in. Look for them. Compensate.
There is a lot to be said for using a known cryptographic object like RC4
to build other tools. It is very valuable to be able to translate any
imagined attack on the system your are proposing into an equivalant attack
on RC4. You then incorporate all past and future analysis of RC4 to your
system.
I agree completely. But also read Schneier's remarks on wide variants of
RC4 -- which were my inspiration to use a wide variant. The math all works
the same, strengths and vulnerabilities.
[...]
... All entropy deposits are
RC4-encoded to prevent any chosen-entropy attack.
You would call deposit at opportune times like key presses, mouse moves,
disk and network I/O. Because i and j are reset so often and because nonces
and deposits are likely to be short, the begining of the S arrray will get
more mixing than the rest of the array. Therefore, it might be desirable to
stir the S array throughly every so often, perhaps by calling mix(0)
repeatedly during idle time.
That's one of the places where we differ. I never directly add in entropy
deposits. I run a separate entropy pool that is hash-based, and
periodically tap that pool to update the secondary pool. I get really
nervous about adding entropy directly into a single pool. I also like to
capitalize on the properties of hash functions for prepping the entropy.
Jon
