Columbia crypto box

[Steven M. Bellovin]

In message <5.1.0.14.2.20030211131643.02a92418 at 203.30.171.11>, 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 majordomo at wasabisystems.com