[1092] in Kerberos_V5_Development
Proposal for API change: krb5_init_random_key
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu May 2 17:46:07 1996
Date: Thu, 2 May 1996 17:45:12 -0400
To: krbdev@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
Currently, krb5_init_random_key takes a (krb5_keyblock *) as a source of
data for the random stream initialization.
Problem:
Sometimes the source of random data is not always in the form of a key,
and the random number initialization routines should be able to accept
data that is not necessarily in that form. For instance, there may be a
good source that produces 512 bits of randomness, and it should not be
the responsibility of the application to convert it into a DES-key to
initialize the DES generator, and then a 3-DES key to initialize the
3-DES generator.
Proposal 1:
I suggest that krb5_init_random_key take a (krb5_data *) as an input,
instead of a (krb5_keyblock *). The initialization routines should
munge that random stream as necessary to obtain the maximum entropy
necessary to initialize the random number generator. I already have
modifications for DES and 3-DES to n-fold data, and do the necessary
parity and weak key adjustments.
Impact:
Several callers of krb5_init_random_key will need to be changed,
including kdc, kdb5_edit, libkrb5:krb5_generate_subkey(), libdes425, and
possibly a few other files. It is expected that very few sites are
actually using this routine in their application. However, since it is
an "exported" API routine of libcrypto, Ted and I felt that we ought to
ask for your opinion.
Proposal 2:
To maintain API compatibility, I have a workaround where the keyblock
that is passed in to DES doesn't actually use the enctype information,
but instead is treated as a krb5_data by the DES routines (in other
words, I only use the "length" and "contents" fields of the keyblock
structure, ignoring the enctype).
Impact:
While the API would be compatible, the code will be more confusing.
This is overloading the keyblock structure to also act as a krb5_data
structure by ignoring other fields. One way to alleviate some of this
is to assign a nonsensical enctype to the keyblock, such as
ENCTYPE_NULL.
Comments? Suggestions?
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
