RE: [LinkSec] RE: algorithm choices - criteria
Mick,
I have indeed seen the CWC paper, Allyn provoked me into putting in some time on it. I'm in the process of trying to understand how far the internal parallelism allows it to be stretched, but on the surface it seems to have desirable properties and deserves proper consideration against our current list (of 2). Mats was way ahead of me, but I plead lack of brain cycles.
Another thing I'm trying to get right in my head is how things stack up when faced with many short packets. The block level parallelism within a packet disappears if you you only have one block, but then you might employ packet level parallelism with a hit on latency. I will probably end up with some graphs that state the obvious, only it isn't obvious to me right now, since its gone 10.30pm.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org] On Behalf
> Of Mick Seaman
> Sent: Tuesday, September 30, 2003 6:27 PM
> To: stds-802-linksec@ieee.org
> Subject: [LinkSec] RE: algorithm choices - criteria
>
>
>
>
> I would commend the internet-draft that Mats points to below to the
> attention of fellow "net-heads". While I can't evaluate or
> comment on the
> comparative security claims from a "security-head" point of
> view CWC-AES
> does seem to have some very nice widely understandable
> functional properties
> when viewed as a candidate for the default algorithm. Also
> the paper is very
> clearly written. Perhaps a candidate algorithm to measure
> other candidates
> against? Purely from the process point of view I am
> interested in seeing a
> very short list a.s.a.p since I am sure that reducing the
> list from 2 to 1
> will be an arduous task - better get started!
>
> Mick
>
> Of course, given what I have heard, someone would have to drive the
> NIST/FIPS process for this (CWC-AES) to be useable, whatever
> its claimed
> merits. See Russ' comments below.
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mats
> Näslund
> Sent: Tuesday, September 23, 2003 4:41 AM
> To: Russ Housley
> Cc: stds-802-linksec@ieee.org
> Subject: Re: [LinkSec] RE: algorithm choices - criteria
>
>
>
>
> Btw, Russ (and others),
>
> Have you had a look at
>
> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-01.txt
>
> ?
>
> /Mats
>
> Russ Housley wrote:
> > Mats:
> >
> >
> >>>Outside of the OCB and CCM options, as you correctly
> suggest there are
> >>>alternatives, but I have tried to restrict myself to the
> modes described
> >>>and discussed in the ongoing NIST modes process. If you can bring a
> >>>proposal for an alternative mode that is superior to the
> CCM and OCB,
> >>>please do so. I believe the reasoning for selecting these
> modes is based
> >>
> >>I don't claim that the following proposal is superior, but it
> >>has some very attractive properties, yet it is often forgotten.
> >>
> >>Carter and Wegman described how to get *unconditionally* secure MICs
> >>using families of universal hash functions. Clearly, integrity is
> >>very important (without it, attacks against confidentiality may be¨
> >>launched). There are also some very efficient implementations of
> >>(almost) universal hash functions, e.g. the MMH functions and
> >>adoptions thereof to binary fields.
> >>
> >>Of course, there could be performance issues on specific platforms
> >>(I'm not an implementation expert) but a provable security might
> >>be worth a few extra cycles of processing time.
> >>
> >>An MMH type MAC would fit very neatly together with a stream cipher,
> >>e.g. AES_CTR.
> >>
> >>Is it worth to pursue this track? At least to investigate
> the possibilties
> >>before we decide?
> >
> >
> > 802.11i looked into this quite deeply. There are a number of very
> > interesting alternatives in this space. However, none of
> them was on
> track
> > for acceptance by NIST for algorithms that could be
> evaluated under FIPS
> > 140. One thing the group could do is ask NIST to select an
> integrity
> > algorithm for use in this context. I think that there are many
> > applications that could be well served by NIST doing so.
> >
> > Russ
>
>
>
>
>