Subject: RE: [Cfrg] Authenticated encryption

From: Doug Whiting <[email-masked]>
Date: Thu, 24 Apr 2003 10:28:38 -0700

On the hardware speed issue, you can actually go even faster (at the expense
of more area) by building multiple, completely independent AES units for
counter mode, or polynomial evaluators for CWC's polynomial MAC.  That's
what's so nice about parallelizable modes in hardware -- the algorithms
themselves are simply not the bottleneck.  Basically, what happens at very
high speed, for CWC or anything else, is that the difficult part in hardware
becomes simply "feeding" the engines.  But, at 10 Gbps, almost anything you
do will have this characteristic. You don't build 10G systems to save gates
:-)

By contrast, chained modes such as CBC cannot be paralellized regardless of
the amount of hardware you throw at it.  

> -----Original Message-----
> From: David Mcgrew [mailto:[email-masked]]
> Sent: Thursday, April 24, 2003 6:53 AM
> To: John Viega
> Cc: [email-masked]
> Subject: Re: [Cfrg] Authenticated encryption
> 
> 
> John,
> 
> At 10:52 PM 4/15/2003 -0400, John Viega wrote:
> >Nice work!  I'd also like to point people to another new 
> authenticated
> >encryption mode called CWC:
> >
> >         
> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt
> >
> >The main thing that CWC offers that other such modes don't is
> >that is that it is simultaneously patent-free, provably-secure and
> >parallelizable (meaning that it will be suitable for 
> securing data over
> >10 gigabit/sec links).
> 
> this is the great property of CWC.  The inability to pipeline 
> chained modes 
> like CBC or CBC-MAC makes those modes cost significantly more 
> in hardware 
> at speeds like 10gbps.   I'm not sure exactly what the speed 
> limit for 
> those modes are (and I'd be glad to hear from someone on the 
> list with a 
> hardware design background), but intuitively, I'd expect that 
> an AES mode 
> that can be pipelined can go ten times as fast as one that is 
> chained, 
> since I'd guess that a single AES round defines the length of 
> the critical 
> path in the AES computation.
> 
> For others on the list who may wonder what CWC has that UST 
> and TMMH don't 
> (besides a more compact description :-),  another good 
> property of CWC is 
> that its key size is small.  This is especially important for 
> hardware 
> implementations, since the operation of fetching the correct 
> decryption/authentication key can be a significant bottleneck in a 
> high-speed system.
> 
> David
> 
> 
> >We will be releasing the full version of our paper 
> (including security
> >proofs) shortly.
> >
> >There are some minor issues we'll fix in the next version of 
> the draft,
> >such as using bit lengths to refer to CWC instances, instead of octet
> >lengths (i.e., AES-CWC-256 instead of AES-CWC-32).
> >
> >John
> >
> >_______________________________________________
> >Cfrg mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 24 Apr 2003 14:01:52 -0400

In message <[email-masked]>, Doug Whi
>do will have this characteristic. You don't build 10G systems to save gates

Right.  The problem with counter mode is that (a) we don't have MACs 
that are correspondingly fast, and (b) counter mode desparately needs a 
MAC.  That's why we need things like CWC.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)