Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[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