[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CBC makes Implementations too Slow.
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?
Khaja
===============================
Cavium Networks, Inc.
2880 Zanker Rd, Suite 102
San Jose, CA 95134
Khaja E. Ahmed
VP Software Engineering
(408) 570-0911 Ext 13
(925) 462-0453 Home office
(925) 989-6564 Cell Phone
khaja.ahmed@cavium.com
http://www.cavium.com/
================================
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin
> Sent: Tuesday, October 30, 2001 8:51 AM
> To: mahdavi
> Cc: ipsec@lists.tislabs.com
> Subject: Re: CBC makes Implementations too Slow.
>
>
> In message <00b001c16159$4987ba60$0300a8c0@payampardaz>, "mahdavi" writes:
> >This is a multi-part message in MIME format.
> >
> >------=_NextPart_000_002E_01C16174.3E8E5360
> >Content-Type: text/plain;
> > charset="windows-1256"
> >Content-Transfer-Encoding: quoted-printable
> >
> >Hi Sirs.=20
> >Hardware implementation of IPSEC is our activity.=20
> >now we face with a problem about CBC mode.=20
> >
> >In software CBC makes no trouble for implementation but in hardware it =
> >is another story.=20
> >If CBC mode was not mandate, acheiving high speed cryptography
> was easy. =
> >
> >
> >for example for 3des every block needs 48 pulses to be encrypted. ( 16 =
> >round )
> >
> >This leads us to a Pipeline that can generate one encrypted block per =
> >clock. but with CBC we can not reach to this speed. result of
> evry block =
> >has an effective role in making next block.=20
> >in another word feeding every block needs result of pervious block at =
> >first.=20
> >
> >so our pipeline faces with terrible lack of efficiency.=20
> >
> >now how can we face with this problem.=20
> >
> >can any body shows us some guide lines?
>
> This complaint is common for all sorts of encryption, not just IPsec.
> The Security Area has decided to wait for the forthcoming
> recommendations from NIST for new modes of operation that are
> specifically designed to address this problem.
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at
http://www.wilyhacker.com
References: