[1041] in Kerberos_V5_Development
Re: GSS confusion
daemon@ATHENA.MIT.EDU (Richard Basch)
Sun Mar 31 19:31:07 1996
Date: Sun, 31 Mar 1996 19:30:27 -0500
To: Marc Horowitz <marc@MIT.EDU>
Cc: "Richard Basch" <basch@lehman.com>, krbdev@MIT.EDU, tytso@MIT.EDU
In-Reply-To: <9603312314.AA07119@portnoy.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Sun, 31-March-1996, "Marc Horowitz" wrote to "Richard Basch, krbdev@MIT.EDU, tytso@MIT.EDU" saying:
> >> Are there any requirements that the checksum only be 8 bytes? I don't
> >> particularly relish the concept of doing cbc encryptions of the md5
> >> digest and tossing subsets. With DES, that may be ok, but with 3-DES,
> >> at least I would rather have the encrypted 16 byte digest.
>
> John Wray has as an internal agenda item minimizing differences
> between krb5 and dce. He will likely complain at this change. IMHO,
> this limits us too much, and as I have never seen a public dce gssapi
> document, I'm not tempted to care very much.
Well, I couldn't get anything but an 8-byte checksum to work, anyway.
However, if I could, I'd like to see it.
Minimizing differences? Well 3-des doesn't exist in the DCE version, so
it is probably a moot point, and won't conflict with any existing
implementations. It might affect the implementations when people try to
adapt it to incorporate these new features, but that is simply due to
bad coding practices.
Anyway, there is still a problem that will have to be wrestled with... I
noted that the gssapi code does not match the spec with regards to
checksums, as it stands. Basically, the checksum is being performed
with the key as the ivec instead of a zero ivec.
> >> Like the DES MAC case, the MD5 digest will have a cbc encrypt operation
> >> (except in this case it is the 3-des cbc encrypt operation) done with a
> >> zero ivec, and the last 64 bits will be used as the 8 byte checksum.
>
> Can you say that again? If I read that right, it means that the
> checksum you've defined will be quite slow. I'd like to see something
> faster.
Ok, I'll restate it... compute an MD5 checksum over the message
(prepending it with the first 8 bytes of the token header), and then do
a DES3-CBC encryption of the MD5 checksum with a zero ivec. The net
result is I am only doing a DES3 operation over two DES blocks.
Is that a bit clearer? However, for now, until I can get it to work
with a 16 byte checksum, I am only able to keep the last 8 bytes. This
is weaker than I prefer... Even a 16 byte checksum seems weaker than
the keyspace, but I don't really want to define a 24 byte checksum
algorithm as that will take a lot more cryptoanalysis than I have time
to do (not to mention the time it takes to pass it by Uri and Steve).
--
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
