In message <[EMAIL PROTECTED]>, Greg Rose writes : >At 06:12 PM 2/10/2003 -0500, Steven M. Bellovin wrote: >> >In any case, WEP would clearly look very different if it had been designed >> >by cryptographers, and it almost certainly wouldn't use RC4. Look at >> >CCMP, for instance: it is 802.11i's chosen successor to, and re-design >> >of, WEP. CCMP uses AES, not RC4, and I think that was a smart move. >> > >> >>A block cipher is clearly a better choice here. But there were some >>rational reasons for selecting RC4 (even though I think that on >>balance, the choice was very wrong). > >I agree that on balance, the implementation of RC4 for WEP was very wrong. >But by your own numbers (and on the assumption that RC4 generates bytes >twice as fast as AES and that the cost of keying is equivalent to >generating 256 bytes) RC4 should win, computationally, on packets greater >than 256 bytes.
As I said, there was some rational engineering in there... > >More modern stream ciphers such as SOBER-t32, SNOW2.0 and Turing, all of >which explicitly support Initialisation Vectors to generate distinct >streams, perform much better than AES for a job like this. I happen to have >the numbers to hand for a comparison of my implementation of Turing vs. >Brian Gladman's highly optimised AES (because the paper is being presented >in two weeks at FSE), and computationally speaking Turing overtakes at >about 100 bytes and generates bytes about 5 times faster from there on. >SNOW2.0 overtakes almost straight away, and generates bytes about 3 times >faster (haven't measured that myself, but I believe it). The combination of >Turing for encryption and HMAC-SHA-1 for MAC outperforms AES even in OCB >mode on my laptop. > >(Lest anyone ask, no, I'm not suggesting adopting Turing or SNOW2.0... >they're too new. And I'm not trying to promote my own cipher particularly. >But...) > >You said: "A block cipher is clearly a better choice here." This is almost, >for me, the canonical case for a stream cipher. What's clear to you isn't >clear to me. Can you elucidate, please? We have a set of independent messages here. Stream ciphers are generally intended for -- well, streams. TLS is a good example of where I think they can be used. They also work well with asynchronous bytes with irregular arrival time, with a requirement for very low overhead (i.e., typed characters, except for the lack of error propagation and the predictable change issue). We have here a set of discrete blocks, with no connection between them. While I certainly agree that a MAC is necessary even with a block cipher, it's much more critical for a stream cipher, given the ability (noted by Borisov et al.) for an attacker to change bits in the destination IP address to cause the packet to be routed to a host of the attacker's choice. Whether or not that can be done profitably with a block cipher would depend on the cipher's block size and the packet format. But it may, ultimately, be a matter of taste.... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]