RE: Two AES encryption modes?

[Scott Fluhrer <sfluhrer@cisco.com>]

At 06:34 PM 7/24/02 , Gregory Lebovitz wrote:
>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).

Well, last year I published "A tale of three transforms", which compared
and contrasted three proposed AES based transforms on a variety of criteria.
No one disagreed with it (or at least no one was willing to tell me about
their disagreement).  I went ahead and revised it by omitting any
references to the IAPM transform (which is not currently under discussion),
and modified the counter mode evaluation for Housley's proposal, which
differs in a number of points from the initial proposal:


The goal of this memo is help the IETF specify the AES based IPSec
transform, by comparing and contrasting two specific proposals by a
variety of criteria.

Two draft RFCs have been published to specify how AES will be used within
an IPSec transform.  These two drafts are:

A CBC mode draft (referred to as CBC within this memo):
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-04.txt

A Counter mode draft (referred to as COUNTER within this memo):
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt

The author welcomes any correction to these evaluations, and any
additional criteria that these proposals should be evaluated against.


A few notes on the ground rules used for these evaluations:

We will assume that the IPSec SAs will require message authentication,
and hence for the purposes of the evaluation, the CBC and COUNTER drafts
will be used along with an authentication transform.

We also note that there are a variety of ways to tweak these proposals
to reduce some of the listed drawbacks.  However, these tweaks tend to
add drawbacks elsewhere.  Because of this complexity, we will examine
the proposals as written.


The actual evaluations:


Security Claims:

Both transforms claim to offer privacy equivalent to the underlying
block cipher (for the number of messages that IPSec can transmit before
rekeying).   Neither makes any authentication claims.


Confidence in the Security Claims:

This section is, necessarily, a matter of opinion.  However, we all feel
good with CBC -- we have used it with all previous block-cipher based
transforms.  We don't have as much experience with COUNTER mode, however,
there is enough to feel comfortable with it.


Completeness of Specification:

CBC is a complete specification -- it appears that the authors have
specified enough to allow interoperable implementations to be created.
COUNTER also appears to be complete.


Packet Size:

COUNTER has the shortest packets -- there is a short (8 byte) IV and
supports minimal padding.  Hence, the overhead is 9-12 bytes, along
with the overhead from the authentication transform.  CBC is rather
larger -- there is a 16 byte IV, 1-16 bytes of padding, and the
overhead from the authentication transform.


Speed of Software Implementation:

Both transforms can be executed in approximately the same speed.
However, both CBC and COUNTER also require authentication transforms to
be executed.


Speed of Hardware Implementation:

This evaluation assumes an aggressively parallized hardware
implementation.  COUNTER is parallizable, but then brings us the
question of how to make the authentication transform equally fast.
CBC is necessarily slow in the encrypted direction, because the block
cipher evaluations must be done serially.


Intellectual Property Issues:

There is no know intellection property issues with CBC or COUNTER, and
there is sufficient prior art to make it quite unlikely that any will
arise.


Fit within Existing Security Architecture:

CBC and COUNTER fit into the existing security architecture as
encryption transforms.


Strength against Faulty Implementations:

By faulty implementation, we refer to accidental faults that allow
implementations to interoperate, but cause security risks.  We do not
consider faults available to malicious implementations, as side
channels exist independent of the transform.  With CBC, the worst
fault appears to be if the IV generation reuses the same IV. This would
allow the attacker to see if the first blocks of the encrypted data are
reused, however, this does not appear to be a severe problem.  COUNTER
has the most severe problems -- if a faulty keying mechanism reuses the
same keys and IVs between sessions, then an attacker can gain
considerable information on the encrypted data.