[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A tale of three transforms
The goal of this memo is help the IETF specify the AES based IPSec
transform, by comparing and contrasting three specific proposals by a
variety of criteria.
Three draft RFCs (of various levels of completeness) have been published
to specify how AES will be used within an IPSec transform. These three
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-01.txt
A Counter mode draft (referred to as COUNTER within this memo):
http://www.ietf.org/internet-drafts/draft-mcgrew-ipsec-scesp-02.txt
A draft based on the new IAPM mode (referred to as IAPM within this memo):
http://www.ietf.org/internet-drafts/draft-jutla-ietf-ipsec-esp-iapm-00.txt
The author welcomes any correction to these evaluations, and any
additional criteria that these proposals should be evaluated against.
Full disclosure: the author of this memo is a coauthor of the COUNTER
draft.
A few notes on the ground rules used for these evaluations:
IAPM also provides authentication. 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. However, IAPM does not strictly define how
the random vector r is generated. Following the recommendation in
section 2.2, we will assume that 96 bits of explicit IV, along with the
32 bit sequence number, will be used to generate the r vector.
The actual evaluations:
Security Claims:
All three transforms claim to offer privacy equivalent to the underlying
block cipher (for the number of messages that IPSec can transmit before
rekeying). In addition, IAPM claims to offer authentication equivalent
to the underlying block cipher. Neither CBC nor COUNTER make 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. IAPM is quite new. There
do exist security proofs for it, which have been reviewed by competent
cryptographers, however, we'd all feel better if it had been around for
a while first.
Completeness of Specification:
CBC is a complete specification -- it appears that the authors have
specified enough to allow interoperable implementations to be created.
COUNTER is not quite complete -- the issue of key length is never
addressed. In addition, it appears likely that the exact specification
will change somewhat. IAPM is not at all complete -- the listed draft
is more a specification of a block cipher mode rather than an ESP
transform.
Packet Size:
COUNTER has the shortest packets -- there is no IV and supports minimal
padding. Hence, the overhead is 1-4 bytes of padding, 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. IAPM is also comparatively large -- a 12
byte IV, 16 bytes of encrypted checksum, and 1-16 bytes of padding.
Speed of Software Implementation:
All three transforms can be executed in approximately the same speed.
However, CBC and COUNTER also require authentication transforms to be
executed, hence IAPM would be somewhat faster.
Speed of Hardware Implementation:
This evaluation assumes an aggressively parallized hardware
implementation. IAPM is the fastest, in that it is inherently
parallizable. COUNTER is equally 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. IAPM is patent pending by IBM. However, the listed draft
reflects refinements by Phillip Rogaway, and it is unknown how that
affects the intellection property.
Fit within Existing Security Architecture:
CBC and COUNTER fit into the existing security architecture as
encryption transforms. IAPM does not -- the security architecture will
need to be extended to include transforms that does both encryption and
authentication.
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. With
IAPM, a problem would occur only if both the IV and the key are reused
between sessions. This would allow the attacker to see duplicate
blocks between sessions, however, this would require multiple faults,
so it does not appear to be likely. COUNTER has the most severe
problems -- if a faulty keying mechanism reuses the same keys between
sessions, then an attacker can gain considerable information on the
encrypted data.