[1076] in Kerberos_V5_Development
3des question
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Thu Apr 18 04:05:49 1996
To: basch@lehman.com
Cc: marc@MIT.EDU, krbdev@MIT.EDU
Cc: perry@piermont.com
Date: Thu, 18 Apr 1996 04:06:03 EDT
From: Marc Horowitz <marc@MIT.EDU>
(Perry: we're in the process of coming up with a decent hash to use
with the gssapi krb5/triple-des mechanism. If you have any useful
input, we'd be interested.)
Richard,
In your code, it looks a lot like with cksum_type == 0 (DES MAC MD5),
instead of MAC'ing the MD5 of the data, you encrypt the MD5 of the
data and use only bytes 8..15. In fact, the call to calculate the DES
MAC is in there, but #if 0'd out. What's the deal with this?
For the triples-des case, Schneier points out on p. 459 of the 2nd
edition that encrypting a hash is subject to certain attacks.
I propose that we define a new checksum type which may be implemented
for single-des and must be implemented for triple-des, which follows
the same form as rfc1828 (IP authentication using keyed MD5). This
rfc has received considerable review by cryptographers. It is also
described in Schneier (as H(K,p,M,K)):
Here's a quote of the relevant part of the rfc:
The 128-bit digest is calculated as described in [RFC-1321]. The
specification of MD5 includes a portable 'C' programming language
description of the MD5 algorithm.
The form of the authenticated message is
key, keyfill, datagram, key, MD5fill
First, the variable length secret authentication key is filled to the
next 512-bit boundary, using the same pad with length technique
defined for MD5.
Then, the filled key is concatenated with (immediately followed by)
the invariant fields of the entire IP datagram (variant fields are
zeroed), concatenated with (immediately followed by) the original
variable length key again.
A trailing pad with length to the next 512-bit boundary for the
entire message is added by MD5 itself. The 128-bit MD5 digest is
calculated, and the result is inserted into the Authentication Data
field.
Of course, instead of the datagram, we would use the (possibly padded)
plaintext.
This hash is still only good for 2^128 bits. Triple-des gives us
2^168 bits of key. There is clearly a potential for collision here.
Does this really matter? Perry, have you addressed this issue in your
IPSEC implementation work?
Marc
