RE: Two AES encryption modes?

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> >The real
> problem in terms of
> > bandwidth consumption was permutation explosion, which has
> also been solved
> > in IKEv2.
>
> Unless I've missed something, the use of suites rather than individual
> combinations of transforms -- which is precisely what we are
> debating --
> is how that was solved.  The problem with transforms is not
> that they are
> individually bulky, but that they come in swarms, not one at a time.

I guess you did miss something. The permutation explosion was solved in
IKEv2 by making the encoding more compact. Instead of:

IKEv1: (3DES and SHA) or (3DES and MD5) or (AES and SHA) or (AES and MD5)

you now have:

IKEv2: (3DES or AES) and (SHA or MD5)

whereas with assigned ciphersuites you would have:

xxx: 3DES_SHA or 3DES_MD5 or AES_SHA or AES_MD5

Add an optional IPCOMP and it gets worse.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: Henry Spencer [mailto:henry@spsystems.net]
> Sent: Monday, July 29, 2002 6:52 PM
> To: Andrew Krywaniuk
> Cc: 'IP Security List'
> Subject: RE: Two AES encryption modes?
>
>
> On 29 Jul 2002, Andrew Krywaniuk wrote:
> > A typical transform payload (including the header) for
> IKEv1 will run about
> > 32 bytes for phase 1 and 24 bytes for phase 2. Eight bytes
> of that is the SA
> > lifetime, which has been omitted from IKEv2. The real
> problem in terms of
> > bandwidth consumption was permutation explosion, which has
> also been solved
> > in IKEv2.
>
> Unless I've missed something, the use of suites rather than individual
> combinations of transforms -- which is precisely what we are
> debating --
> is how that was solved.  The problem with transforms is not
> that they are
> individually bulky, but that they come in swarms, not one at a time.
>
> > My claim is not so much that the cost is not important, but
> rather that it
> > will be drowned out by other factors...
>
> My claim is that you need to justify that more -- it's not a
> self-evident
> truth.
>
>
> Henry Spencer
>
> henry@spsystems.net
>