[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CBC makes Implementations too Slow.



In message <GCEGKDEGCPFGJNGILFIPMEJHCHAA.khaja.ahmed@cavium.com>, "Khaja E. Ahm
ed" writes:
>Steve,
>
>I am not sure I understand why this (3DES CBC in silicon) is considered a
>problem and in what types of applications and devices?  Is the problem cost?
>I am not sure that there would be much benefit in waiting for other modes to
>emerge given how cheap and fast silicon is getting.
>
>There are cheaper and faster crypto accelerators available today than ever
>before.  Currently shipping chips deliver, 600 mbps throughput on a single
>stream of 3DES IPsec traffic.  There are also chips that use multiple cores
>to do 2.4 gbps.  We (Cavium) and others have announced even faster chips. We
>expect to deliver chips in Jan that will do 2 gbps in each core.  Given the
>multi core architecture of these chips, they can handle as much 3DES CBC
>IPSec (or SSL/TLS) traffic as the PCI, PCIX and LDT buses can handle.  Mid
>2002 versions will handle at line rate (OC48 and OC192) IPsec and SSL/TLS
>traffic not only 3DES CBC but also AES and arc4.  Is this not sufficient?

I'm not a hardware person; all I can do is listen when hardware folk 
tell me that they can or cannot do certain things.  CBC mode requires 
feedback, which makes it impossible to pipeline encryptions; you can't 
encrypt plaintext block P[n+1] until you have the ciphertext from 
encrypting P[n].  That in turn makes me wonder how multiple cores help 
you, unless it's to let you encrypt two different packets 
simultaneously, for a high aggregate throughput rate.

Anyway -- enough people complained to NIST that they decided that a new 
mode was necessary.  I'm not completely convinced, and I don't think 
that most of the proposed new modes (especially counter mode) will 
really do the job.  Specifically, it does no good to encrypt at such 
rates if you can't authenticate at such rates, too.  (Matt Blaze and I 
wrote a short paper on our concerns for any new modes of operation; see
http://www.research.att.com/~smb/papers/internet-modes.ps or
http://www.research.att.com/~smb/papers/internet-modes.pdf .)

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com




Follow-Ups: