RE: Two AES encryption modes?

["Herbert, Howard C" <howard.c.herbert@intel.com>]

I agree with Paul Koning.  Judging cipher algorithms on their names is NOT a
sensible policy.  AES in CTR mode and other "parallelizable" AES-based
algorithms (e.g., PMAC) are the only viable algorithms that will support
IPsec on 10 Gbit Ethernet systems
like the ones that I am developing.

Howard

-----Original Message-----
From: Paul Koning [mailto:pkoning@equallogic.com]
Sent: Wednesday, July 24, 2002 1:00 PM
To: paul.hoffman@vpnc.org
Cc: ipsec@lists.tislabs.com
Subject: Re: Two AES encryption modes?


>>>>> "Hoffman" == VPNC  <Paul Hoffman> writes:

 Hoffman> 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

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

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

DES and 3DES also have similar names.  It does not make a whole lot of
sense to object to a cipher system proposal on the grounds that its
name sounds like another name.

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

Why would we want to?  The two systems indeed have different
properties.  In particular, they have different performance
properties, which is one significant reason for proposing counter
mode.  What proposals a system makes is entirely its own choice.  I
would not require an implementation to support both modes, much less
propose both -- no more than I would require an implementation to
support, or propose, DES and 3DES both.

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

I disagree strongly.  I don't think judging cipher algorithms on their
name is a sensible policy.

	paul