[1226] in Kerberos_V5_Development
mk_safe vs. mk_priv
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu May 23 00:01:48 1996
Date: Thu, 23 May 1996 00:00:13 -0400
To: krbdev@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
I was analyzing the code structure to see how feasible it would be to
use the key as a generator key only to generate separate encryption and
safe-checksumming keys.
The code does not lend itself to this well...
In fact, it doesn't even lend itself to checksumming well, as there is
no mapping between checksum types and enctypes or vice-versa.
Scenario:
A 3-des session key exists. The checksum list first states that md5-des
should be used. There is nothing in the code that sanity checks to
ensure that the session key type is compatible with the checksumming
algorithm to fall back. This case actually isn't catastrophic, but if
incompatible systems ABC and XYZ were used, you could well imagine a problem.
Back to subkey computation...
Subkey solutions
----------------
Solution 1:
The only real way of generating subkeys in the existing framework
appears to be to hack at the crypto-checksum code to process the
keyblock, considering the input a generator key, and generating a subkey
each time it is called. In the 3-des process_key module, a
similar thing needs to be done with its input key. Needless to say,
this is far from elegant. Also, it assumes that the subkey generation
mechanism we choose is strong and not likely to be compromised, for if
it is, we have a two-fold exposure instead of only one system, and there
will be compatibility problems. We also have to keep in mind that the
developer may be generating subkeys, too... The algorithm that we
implement should generally not weaken their subkey generation.
Solution 2:
We live with potentially using the same key for both systems, and we
should simply document that session keys should not be used for both
checksumming and encryption. If the functionality of both is desired,
it is best to first compute/negotiate sub-keys to perform each function.
This off-loads the burden from us, possibly making it easier for others
to poorly implement a security solution. Also, what we are trying to
avoid is rarely done; very seldom is the same key used by two different
applications (or even the same application) to simply sign data and to
encrypt data.
Comments?
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
