Re: RC4 improvement idea

> I got a paper from the cryptography technical report server  
> "http://www.itribe.net/CTRS/" about a weak class of RC4 keys.  The 
> report said that with some keys, it was possible to predict what some 
> parts of the State-Box would be.  I was thinking of a way to fix this, 
> and had this idea:
> 
> do some sort of hashing function with the key that derives a number 
> between 55 and 500 or something like that, then scrabmle the S-box that 
> many times.  In this way, the chances that the State-Box will have any 
> correlation becomes extremely small.  I think it is 1/125 to begin with 
> anyway, so this would make it around  1/(125*NumPasses).  And since the 
> exact number of passes is a function of the key, the cracker won't know 
> how many times it went through.   I tried this out and having 1000s of 
> passes doesn't effect the randomness of the state-box in any negative 
> way, possibly it makes it more random? If anyone has any thoughts I'd 
> love to hear them.

The S-Boxes in DES were optimized to hinder Differential Cryptanalysis.  I've seen no studies on the effectiveness of jumbling the S-Boxes during encryption -- even Biham and Shamir's book doesn't mention it -- but, I figure, if it helps, DES would probably already be doing it (unless of course the NSA thought the jumbling would make too good an algorithm).

Noel Yap writes:
> The S-Boxes in DES were optimized to hinder Differential
> Cryptanalysis.  I've seen no studies on the effectiveness of
> jumbling the S-Boxes during encryption -- even Biham and Shamir's
> book doesn't mention it -- but, I figure, if it helps, DES would
> probably already be doing it (unless of course the NSA thought the
> jumbling would make too good an algorithm).

Your conclusion may be correct, but your reasoning is faulty. DES was
built to be run in hardware, which doesn't make S-Box jumbling easy;
it was in fact built to be run on the hardware of twenty years ago,
which was far more constrained than our hardware is now.

Perry