RE: Two AES encryption modes?

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

> Manual keying does NOT, I repeat NOT mean identical IVs.  The two
> implementations I worked on (NRL, Solaris) use random (for "random" ==
> /dev/urandom strength) IVs regardless of how IPsec SAs are derived.

I agree that fear of IV reuse is not a good enough to ban counter mode with
manual keying. Manual keying, after all, does not mean that you never rekey;
you may have multiple pre-installed SAs and you switch over after a fixed
byte count. This implies that you need to keep a rough estimate of the byte
count in non-volatile storage, so it should be always possible to calculate
a unique counter value. Therefore, using random IVs would seem to be
unnecessary.

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: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan McDonald
> Sent: Monday, July 29, 2002 11:58 AM
> To: David Wagner
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Two AES encryption modes?
>
>
> David,
>
> > >2. You want to use manual keying and therefore may send
> more than one
> > >   packet with the same IV.  With CBC that doesn't compromise the
> > >   confidentiality of the data; with counter mode it does.
> >
> > Nitpick: CBC is not really as secure as one might like if
> IV's repeat,
> > however it is true that IV reuse hurts CTR mode much worse
> than CBC mode.
> >
> > If you reuse the same IV with CBC mode, there is some minor
> compromise
> > of message confidentiality (shared plaintext prefixes show
> through as
> > shared prefixes in the ciphertexts); in comparison, IV
> reuse in CTR mode
> > is more devastating (it reveals both plaintexts).
>
> Manual keying does NOT, I repeat NOT mean identical IVs.  The two
> implementations I worked on (NRL, Solaris) use random (for "random" ==
> /dev/urandom strength) IVs regardless of how IPsec SAs are derived.
>
> Dan
>