Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:17:17
Anonymous (nobody@replay.com)
Tue, 3 Nov 1998 04:20:42 +0100
> (2) There is an avalanche problem with the 256th byte to be withdrawn
> because it is processed when the Arc4 I == 0. Its statistics are much
> worse than the 255th or 257th bytes. This problem also affects the Arc4
> cypher.
For reasons very similar to those behind Roos' attack on the key schedule,
chances are about 37% that the first element of the state is affected only
by the first swap of the stream generation process -- effectively
swap (myrc4Sbox[I], myrc4Sbox[myrc4Sbox[I]])
-- then left alone until the next pass. It seemed that the
unpredictability of J would hide this; it evidently does not. No wonder
RC4 got special export status. :)
Byte 255 doesn't have the same problem since I indexes a well-churned
byte, and byte 257 doesn't have quite so much of a problem because I
indexes a byte which is slightly better churned in both the key schedule
and the stream generation.
> Roos' weak key attack on the Arc4 cypher effects the early outputs, so it
> is important to analyse them separately from later bytes.
The problems evidently aren't confined to them, though; I might try and
look more deeply into the issues with the later bytes myself.
> Since the bulk of the state is encoded in the permutation of the 256
> possible bytes in the S box, just checking whether 1/2 of the bits are
> different might not detect a lack of avalanche.
Right. The way RC4 works, the most likely avalanche deficiency seems to be
an output byte being fully independent of a certain small key change
with >1/256 probability; the bit counts probably aren't the best measure.
> Investigate whether using Knuth's algorithm P instead of the Arc4 key
> schedule makes any difference.
I was wondering when someone would bring up the connection between the
shuffler-bias thread and RC4. If certain S-boxes are made much more or
less likely by the key schedule, this could be another problem.
I'm also interested in this because I've been toying with a variant in
which a relative of the key schedule is still used, but it's fed an
expanded key generated by a strong mixing process. That would get rid of
the problems related to Roos' attack, but wouldn't solve any problems that
come from the shuffling itself.
> Bill Frantz Electric Communities
> Capability Security Guru 10101 De Anza Blvd.
> frantz@communities.com Cupertino, CA 95014
> 408/342-9576 http://www.communities.com
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:17:17