Re: alleged-RC4

[Hal <hfinney@shell.portal.com>]

Bill Sommerfeld <sommerfeld@orchard.medford.ma.us> writes:

>Actually, all the %256 operations in the code are superfluous on
>8-bit-byte platforms since the indices are declared as `unsigned
>char'.

Ah, good point.  So my "typo" doesn't really matter (although I think
it is a typo.)

>Probably the only potential weakness I can see is that the `x' and `y'
>counters are always initialized to zero when starting off; this means
>that an attacker can almost always know the `x' value used to encrypt
>each byte of cyphertext they find.  I can't see any way to exploit
>this, though.  It would seem that you could (slightly) strengthen the
>cipher by starting with x=state[0] and y=state[1], then cranking the
>key generation loop for two more iterations..

A related point is how the key-dependent state-table permutation is set
up.  The algorithm is, in pseudo-code,
	for i from 0 to 255
		swap state[i] and state[j]
where j is incremented by state[i] plus the next key byte, mod 256.
Notice the similarity to the naive random-permutation generator:
	for i from 0 to 255
		j = random (256)
		swap state[i] and state[j]
where random (n) returns a random number less than n.  This naive
algorithm is not quite right, as it generates 256 to the 256th power
equally likely arrangements, when there are actually only 256!
arrangements and 256! doesn't even divide 256^256 evenly.  The
similarity I see is that j is chosen in the prepare_key as a slightly
complicated function of the key byte and the current state, and we can
view this as a key-dependent substitute for random (256).  So
it would appear that the prepare_key algorithm, even with a fully
random key, may produce a bias in the permutation table.

A correct algorithm for a random permutation is:
	for i from 0 to 255
		j = random (i+1)
		swap state[i] and state[j]
Here we choose the random number from among the ones we have already
done.  This algorithm can be easily proven correct.  Perhaps it would
be better if the prepare_key algorithm did a similar thing, choosing
the entry with which to swap modulo the current "i" value plus one rather
than mod 256.

One implication of the existing implementation is that there may be a
simple relation between at least state[0] and the first character of
the key.  Initially state[0] will be swapped with the value in the
table at the position of the first byte of the key.  Since the table is
initialized to 0..255, this means that state[0] will hold the value of
the first key byte after that swap.  Now, it is probable that state[0]
will be chosen "randomly" to be swapped with a later entry in the
table.  But as we discussed here a few days ago, there is about a 1/e
chance (about 37%) that it will not be swapped after its first
guaranteed swap.  This means that 37% of the time that this algorithm
is used, state[0] holds the first key byte at startup.  OTOH if the
modification I suggested above were made, no such conclusion could be
drawn and I don't see anything simple you could say about the likely
permutation after prepare_key is complete.

Now, having said this, I don't see any way to exploit this knowledge
to attack the cypher.  The "lookup, sum, and lookup" structure of the
cypher has too many degrees of freedom to allow this information about
state[0] to expose a hint of what the key might be, as far as I can see.
But it is an interesting aspect of the key setup, nevertheless.

Hal