[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keyless Integrity Check Values
Russ,
Thanks for the note of support on keyless Integrity Check Values (ICVs). As
you noted I am a proponent of this class of security techniques. The keyed
integrity mechanisms are not yet widely available in hardware, so the software
integrity check process becomes the most critical factor in improving the
performance of network security. A simple keyless ICV (with message length
either in the ip header or explicit) covered by an encryption algorithm is the
most efficient way to provide the best security (integrity, authentication,
confidentiality).
Paul
_______________________________________________________________________________
Subject: Keyless Integrity Check Values
Author: housley@spyrus.com@INTERNET
Date: 6/8/95 11:19 AM
Encoding: 1630 Text
IPSECers:
I have been traveling a great deal, so I let this issue drop. But I want
to revisit the discussion. The last e-mail I recall on the topic was from
Paul Lambert, and Paul was voicing support for keyless ICVs (a.k.a. keyless
checksums). Before that, Hugo posted a message about attacks on keyless
ICVs. Hugo described the following chosen message attack:
- Construct a message M = M1 | CS1 | M2, where CS1 is the
keyless checksum on M1, and M1 and M2 are arbitrary. The
length of M1 | CS1 should be an integral number of blocks.
- Give M to the party that's encrypting and authenticating,
to obtain C = E (M | CS2), where CS2 is the checksum on M,
and E is the encryption function.
- In typical modes of encryption, it will be the case that
that C = C1 | C2, where C1 = E (M1 | CS1) --- so C1 is a
valid message as far as authentication is concerned
- Replace C1 with C on the transmission line -- the recipient
will accept C1 as authentic
I discussed Hugo's attack with Burt Kaliski, and Burt came to the following
conclusion:
This [attack] works for any kind of checksum, and although
it can be thwarted by including the total message length at
the beginning of the message, it's an attack cryptographers
would like to avoid entirely.
Given that we are interested in protecting IP datagrams as well as TCP and
UDP protocol data units, we should revisit the keyless ICV discussion
because these protocol formats all include payload data lengths.
Russ