[1225] in Kerberos_V5_Development
des3-sha
daemon@ATHENA.MIT.EDU (Richard Basch)
Wed May 22 20:49:06 1996
Date: Wed, 22 May 1996 20:47:26 -0400
To: krbdev@MIT.EDU
Cc: bcn@isi.edu
From: "Richard Basch" <basch@lehman.com>
It may be appropriate if the des3-sha and the crypto checksum employ
some techniques to use the supplied key as a generator key. The key
actually used in HMAC-SHA and for DES3 should be pseudo-independent, in
the fact that the two keys should be different and not derivable from
the other.
Uri Blumenthal (IBM/Watson) suggested the following:
Well, one way would be to request the 300 bits of key. Then use
first 140 (whatever :-) for DES, and the last 160 for HMAC_SHA.
Another way is to use the session key as a generator key, and
derive two pseudo-independent keys from it. Like:
EncryptionKey = SHA("encrypt" + key + "encrypt");
AuthenticKey = SHA("authenc" + key + "authenc");
Not feasible to derive either generator key, or one key from
the other...
Other than that, the only other comments he had about the existing
specification is that my confounder length need not have been increased
from 8 to 24.
The above suggestion of using the des3-keys in the database as mere
generator keys suggests that a few things may need to be changed,
including the addition of a third cksum type.
SHA 9
HMAC-SHA 10
SHA-DES3 11
I feel we should keep SHA and HMAC-SHA as they are fundamental types
that could be utilized by various developers (and possibly GSS-API when
there is a 3-des extension to the spec).
I still need to discuss this further with Uri, but it sounds like the
implemented protocol may only need minor tweaks.
--
Richard Basch
Sr. Developer/Analyst, DSO URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 38th Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
