Subject: RE: [Cfrg] Draft minutes for CFRG meeting in Atlanta

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 26 Nov 2002 07:50:20 -0800

Question, do we really need to address parallelization at the stream
level?

OK so we have a 10Gb/sec firehose feeding us bits.

Let us say we want to apply 8 parallel processing units to the problem.

One approach (the hard way) is to look for some means of precalculating
or otherwise parallizing the processing steps necessary to implement the
cipher block chaining algorithm.

Another approach would be to establish 8 independent (or
quasi-independent) sets of keying information and then partition the
stream into 8 interlaced substreams, so taking 4 substreams for the sake
of simplicity we would have:

A B C D A B C D A B C D [A] [B] [C] [D]

where [X] stands for the checksum of stream X.

It may even be possible to collapse down the 4 separate checksums into
one with appropriate cryptographic caution likely to be chaining mode
dependent.

OK so this is not as pretty as doing the thing in an integrated fashion,
the sender and receiver have to negotiate features such as the number of
streams to use. However I assert that if you are going to insist on
being on the bleeding edge such pain should be expected. Wherever a
10Gb/sec sender is to be found there had better be a 10Gb/sec receiver
connected thereto and the two had better have a somewhat intimate
relationship if the implementation technology is clocked at 2GHz or
so...

So ultra parallel composability is a 'nice' feature but certainly not
interesting enough to get all hot and patent encumbered over.

		Phill

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 9:19 AM
> To: Brian Weis; [email-masked]
> Subject: Re: [Cfrg] Draft minutes for CFRG meeting in Atlanta
> 
> 
> Brian:
> 
> Please see corrections below.
> 
> Russ
> 
> 
> 
> >CM: Counter Mode with CBC-MAC
> 
> CM -> CCM
> 
> >Russ Housley, RSA Labs
> >-----------------------------
> >
> >Russ Housley gave a presentation on his Counter Mode with 
> CBC-MAC (CCM)
> >mode draft (draft-housley-ccm-mode-00.txt).  It is a combined mode of
> >operation (providing both encryption and authentication).
> >
> >CCM is currently  mandatory to implement in the IEEE 802.11i 
> draft, and
> >has been submitted to NIST for consideration as a mode for 
> AES. Multiple
> >implementations are available, and information on them is 
> available at
> >http://www.hifn.com/support/scm.htm. Russ would like to published CCM
> >as an Informational RFC, and this group seems to be an 
> appropriate place
> >for submittal.
> >
> >Russ mentioned that CCM may be covered by up to three 
> different patents,
> 
> NO!  Alternatives to CCM, such as OCB, may be covered by these 
> patents.  CCM is the only authenticated encryption algorithm 
> that I know 
> about that is not encumbered.
> 
> >but each of the authors has been gracious enough to 
> explicitly release
> >any IPR rights into the public domain.
> >
> >David asked about performance limits of CCM. Russ replied that
> >one of the motivating factors for this work was for the mode to
> 
> Only the encryption part is parallelizable.  The 
> authentication is not.
> 
> >be parallelizable. The encryption key stream of the mode is even
> >pre-computable. So the limiting factor is the CBC-MAC integrity
> >operation. He doesn't have any good data on when that becomes the
> >bottleneck. Someone mentioned that in this application, the 
> constrained
> >engineering limitation is the amount of resource available to do the
> >processing. Dealing with the device limitations was a more important
> >consideration than speed.
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg
>