----- Original Message -----
From: "Jeremy Lennert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 23, 2002 8:15 AM
Subject: CDR: Re: Jail Cell Cipher (modified RC4)
> > Unfortunately it has a rather damning effect on the cipher.
> > First in the key
> > scheduling there is a distinct possibility of keys that are
> > impossible. It
> > assumes that all K[i] are generators mod 37, so using a key
> > where the offset
> > is 0 will result in an infinite loop in the key scheduling, this is
> > obviously a bad design decision. Second the distinguisher
> > from random for
> > such a small RC4 state would require a relatively small known
> > plaintext. In
> > fact at that size I think there are better attacks against it than the
> > distinguishers known for full sized RC4. I believe it would
> > be achievable to
> > actually determine that complete state, although it would take more
> > significant amounts of work than would be applied to most
> > inmate mail (an
> > encrypted message would probably be simply discarded and
> > never delivered).
>
> The specification for the key requires all key values to be nonzero. From
> the web site:
>
> "an array of key values K, where each value is a nonzero alphabetical
> character or its numerical equivalent"
>
> However, there was an error in the source code that allowed zeroes in the
> key. This has been corrected. Any zeroes in the key definition now cause
> the program to abort with an "invalid character" error message.
>
>
> Regarding the distinguisher, I don't think I understand how distinguishing
> the keystream from random amounts to an attack that will recover the
> internal state. Could you offer further clarification on that?
In this case they are two different attacks. The first attack being the
distinguisher which will let the attacker read the plaintext, but not
necessarily find the internal state. The second an attack on the internal
state where the known small variations in the state between outputs could be
used to compute a state that is at least a full collision on the outputs.
> Incidentally, for paper-and-pencil applications, I'm assuming that the
> message length will not exceed about 100 characters.
I think that will be small enough to save the security of the system, but
I'm not sure.
> The problem with using full RC4 is not in the actual keystream generation,
> but in running the key-scheduling algorithm. Even if we only ran the KSA
> for one round through the permutation table, estimated time is about 50
> minutes (not necessarily impractical, but making many rounds to improve
> security or repeated trials to improve accuracy very difficult) and the
> chances of performing that entire round without error for my current best
> estimations of accuracy are about 1 in 150,000.
Why not just memorize the permutation table? It's only 37 characters. Also I
don't see where a difference of an hour or two will necessarily make a
difference, the point of incarceration is that you can't go out and do
anything you want, you have to sit in your cell for 23 hours a day. So
anything that you can encrypt in 23 hours is good enough. By your estimates
that gives time for 27 KSAs (which wouldn't increase security in the
slightest, a permutation is a permutation) which I think should be more than
enough KSAs for any reasonable demands.
> For the modified RC4, accuracy still isn't great, but it is good enough
that
> careful error-checking may leave the algorithm feasible in terms of both
> time and accuracy.
It's the security of the scheme, not the usability, that I am questioning. I
think the artifacts of RC4 will be enhanced to the point where the security
is, for all practical purposes, useless. The only question remaining in my
mind is how long before those artifacts can be detected and/or made use of?
Joe
