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

RE: CBC makes Implementations too Slow.



Steve,

You are quite right - sorry if I did not make this clear.  Multiple cores
only help if there are multiple streams or IPsec tunnels.  As you point out
a single stream can not be parallelised and the packets would have to be
serially processed.  This limts the performance to that of a single core - 2
gbps for example.  That said, I am not sure that this is a major limitation.
Having multiple cores only helps when you have multiple IPsec tunnels for
example.  Thus 8 cores could provide bandwidth of 16 gbps, assuming >= 8
tunnels and that no single tunnel requires bandwidth in excess of 2 gbps.
The devices available also have authentication, look up and other
capabilities that are necessary to not only do 3DES-CBC but full IPsec
packet processing at these rates.

Thus the point remains that it may not be necessary or helpful to
invent/explore other modes of DES when the problem of too slow encryption
has essentially been eliminated.

Khaja

> -----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 4:56 PM
> To: Khaja E. Ahmed
> Cc: mahdavi; ipsec@lists.tislabs.com
> Subject: 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: References: