Bill Frantz writes: >>> * Fast key setup (Forget tossing the 256 bytes of key >>> stream. The designers weren't crypto engineers. >>> Personally, I'd toss the first 1024.)
Steven M. Bellovin wrote: >> There may be a cryptographically sound reason to >> discard that much, but it's not without cost. Bill Frantz wrote: > The reason I would discard so much is that when I did some > statistics on RC4 output, I kept getting distribution lumps > out to about 1024. They made me worry about what someone > who knew what were doing could do. See: Ilya Mironov (Stanford), (Not So) Random Shuffles of RC4 Advances in Cryptology - CRYPTO 2002 Proceedings, ed. by Moti Yung. Springer LNCS 2242, 2002. pp. 304-319. http://crypto.stanford.edu/~mironov/papers/rc4full.pdf Abstract. Most guidelines for implementation of the RC4 stream cipher recommend discarding the first 256 bytes of its output. This recommendation is based on the empirical fact that known attacks can either cryptanalyze RC4 starting at any point, or become harmless after these initial bytes are dumped. The motivation for this paper is to find a conservative estimate for the number of bytes that should be discarded in order to be safe. To this end we propose an idealized model of RC4 and analyze it apply- ing the theory of random shuffes. Based on our analysis of the model we recommend dumping at least 512 bytes. ... 7 Conclusion We identified a weakness in RC4 stemming from an imperfect shuffing algorithm used in the key scheduling phase and the pseudo-random number generator. The weakness is noticeable in the first byte but does not disappear until at least the third or the fourth pass (512 or 768 bytes away from the beginning of the output). ... Our most conservative recommendation ... means that discarding the initial 12 * 256 bytes most likely eliminates the possibility of a strong attack. Dumping several times more than 256 bytes from the output stream (twice or three times this number) appears to be just as reasonable a precaution. We recommend doing so in most applications. - --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]