[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: