Re: preliminary version of counter mode draft

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

[responding to 4-month-old mail]

> I'm curious why all of these were here:
> 
> >      twofish128-ctr   RECOMMENDED       Twofish in SDCTR mode,
> >                                         with 128-bit key
> >      twofish192-ctr   OPTIONAL          Twofish with 192-bit key
> >      twofish256-ctr   OPTIONAL          Twofish with 256-bit key
> >      serpent128-ctr   RECOMMENDED       Serpent in SDCTR mode, with
> >                                         with 128-bit key
> >      serpent192-ctr   OPTIONAL          Serpent with 192-bit key
> >      serpent256-ctr   OPTIONAL          Serpent with 256-bit key
> 
> Serpent and Twofish treat 128, 192 and 256 bit keys basically the
> same anyway (unlike AES, where all three different versions might be
> useful). Obviously there is no reason _not to have them all (besides
> a fairly small amount of extra work for implementors), but it seems
> pointless, given that serpent256-ctr and twofish256-ctr would do the
> job of all six of these just fine.

I didn't see a response to this..  

I don't (wg chair hat off) think it makes a lot of sense to any of the
include AES runners-up at anything above OPTIONAL but I don't feel
particully strongly about it either way.

Regarding the key lengths, though, there are enough regulatory/policy
issues out there (for instance, additional paperwork required for
export of sw or hw doing key sizes over 128 bits) that we're better
off specifying and negotiating all believed-to-be-strong key lengths
separately -- if we were to only do a 256-bit version, it might cause
certain vendors to omit the algorithm entirely.

					- Bill