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

Re: CBC makes Implementations too Slow.



At 7:55 PM -0500 10/30/01, Steven M. Bellovin wrote:
>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.

Steve,

I think Khaja's comments indicate that the Cavium chips cam support a 
single SA at up to 600 Mb/s and multiple cores allow an aggregate 
throughout of 2.4 Gb/s, e.g., if one has traffic for multiple SAs, 
since each SA can be independently encrypted.

Steve


References: