RE: Two AES encryption modes?

[Gregory Lebovitz <Gregory@netscreen.com>]

If AES-CTR comes to fruition quickly, can someone put forth an argument for
continuing to use AES-CBC? 

(To clarify, I am not challenging us to drop AES-CBC, I just want to hear
cryptographers explain why we would/would not need both).

-----Original Message-----
From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
Sent: Wednesday, July 24, 2002 9:56 AM
To: ipsec@lists.tislabs.com
Subject: Two AES encryption modes?


At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the IP Security Protocol Working Group 
>of the IETF.
>
>	Title		: Using AES Counter Mode With IPsec ESP
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-ipsec-ciph-aes-ctr-00.txt
>	Pages		: 12
>	Date		: 23-Jul-02

There are technical reasons why this WG might or might not want to 
have more than one AES encryption modes. I would like to bring up a 
non-technical reason why we wouldn't: interoperability.

System A is marketed as doing AES. System B is marketed as doing AES. 
They won't interoperate unless they both do the same modes. Yes, we 
could demand that the users understand that "AES CBC" and "AES 
Counter" are different, and that when they hear "AES" they need to 
ask "which of the two AES modes do you mean"? That is a wholly 
unrealistic demand.

As I understand it, the two modes have very different security 
properties, meaning that it would be unrealistic to require that any 
system that incorporated one had to incorporate both. Even if we went 
that route, it is unlikely that we could enforce (or even explain) 
why all proposals that included one should also include the other.

Without a really, really strong security justification, the loss of 
understandable interoperability that comes with two 
different-but-similarly-named algorithms is not worth it.

--Paul Hoffman, Director
--VPN Consortium