[1079] in Kerberos_V5_Development
Re: 3des question
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Thu Apr 18 10:03:10 1996
To: Marc Horowitz <marc@MIT.EDU>
Cc: basch@lehman.com, krbdev@MIT.EDU, perry@piermont.com
In-Reply-To: Your message of "Thu, 18 Apr 1996 04:06:03 EDT."
<9604180806.AA27133@beeblebrox.MIT.EDU>
Reply-To: perry@piermont.com
Date: Thu, 18 Apr 1996 10:03:02 -0400
From: "Perry E. Metzger" <perry@piermont.com>
The 1828 mechanism was originally proposed by Hugo, but he has since
come up with a much stronger MAC called HMAC which is also based on
MD5 or SHA. If you are looking for a good hash, I strongly suggest
looking at HMAC, especially the variants where you only provide part
of the hash and thus frustrate brute force cracks. Check out Hugo's
internet drafts on the subject. There is now a variant where you XOR
with the pad instead of simply padding but it makes no security
difference...
BTW, I used to think this area was easy, but the cryptographers have
convinced me that MACs are in fact a Hard Topic. Thats why you are
likely best off sticking with what the cryptographers say to use...
.pm
Marc Horowitz writes:
> (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
>
>
