[1697] in Kerberos-V5-bugs
Triple DES
daemon@ATHENA.MIT.EDU (Richard Basch)
Sun Oct 29 19:32:02 1995
Date: Sun, 29 Oct 1995 19:30:46 -0500
To: tytso@MIT.EDU
Cc: krb5-bugs@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
I have yet to identify the problem in the KDC as to why it is not using
the proper encryption types... I have finally convinced myself that the
Triple DES code is not at fault, and is internally consistent, but even
trying to work around the problem in the KDC has proven futile.
Currently it works if it is the only mode used, but not with other
types. Apparently, there has been no testing when there have been keys
of differing sizes, or for anything that does not use DES.
I am going to move on to encrypting telnet and come back to Triple DES
in a couple of weeks, when I have had some time away from that code. I
suspect your upcoming preauth changes may perturb the areas that I will
have to visit to fix the problem (and if I am really lucky, you will
actually address the problem). (Triple DES is basically done, except
for fixing the other problems in the KDC that seem to prohibit its use
with other keytypes in the database.)
Here is a new section for RFC 1510; I didn't see the original nroff
source in the tree, or at least not under the doc directory.
6.3.5. Triple DES in CBC mode with an MD5 checksum (des3-cbc-md5)
The des3-cbc-md5 encryption mode encrypts information under the Data
Encryption Standard (DES) [11] with three encryption keys and using the cipher block chaining mode [12].
An MD5 checksum (described in [16]) is applied to the confounder and
message sequence (msg-seq) and placed in the cksum field. DES blocks
are 8 bytes. As a result, the data to be encrypted (the
concatenation of confounder, checksum, and message) must be padded to
an 8 byte boundary before encryption.
Plaintext and DES ciphtertext are encoded as 8-octet blocks which are
concatenated to make the 64-bit inputs for the DES algorithms. The
first octet supplies the 8 most significant bits (with the octet's
MSbit used as the DES input block's MSbit, etc.), the second octet
the next 8 bits, ..., and the eighth octet supplies the 8 least
significant bits.
Encryption under DES using cipher block chaining requires an
additional input in the form of an initialization vector. Unless
otherwise specified, zero should be used as the initialization
vector. Kerberos' use of DES requires an 8-octet confounder.
Triple DES Electronic Code Book (ECB) encryption is accomplished by
encrypting an 8-octet data block with the first DES key. The result
is then confounded by performing a DES decryption with the second key.
That result is then encrypted with the third DES key.
In cipher block chaining mode, the first 8-octets is eXclusive-ORed
with the initialization vector prior to performing the Triple DES ECB
encryption of the block. Subsequent 8-octet blocks are eXclusive-ORed
with the cipher output of the previous block prior to performing the
Triple DES ECB encryption of that data block.
The DES specifications identify some "weak" and "semiweak" keys;
those keys shall not be used for encrypting messages for use in
Kerberos. Additionally, because of the way that keys are derived for
the encryption of checksums, keys shall not be used that yield "weak"
or "semi-weak" keys when eXclusive-ORed with the constant
F0F0F0F0F0F0F0F0.
A triple DES key is 24 octets of data, with keytype five (5). The
key consists of three 8-octet DES keys. The first eight octets are
used to perform the first DES encryption. The next eight octets are
used to perform the confounding decryption. And the last eight octets
are used to perform the final DES encryption.
To generate a DES key from a text string (password), the text string
normally must have the realm and each component of the principal's
name appended(In some cases, it may be necessary to use a different
"mix-in" string for compatibility reasons; see the discussion of
padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
boundary. This string is then fan-folded and eXclusive-ORed with
itself and bit sliced to form three 8 byte DES keys. The parity is corrected on each
key, and they are used to generate a 3-octet Triple DES CBC checksum on the initial
string (with the realm and name appended). Next, parity is corrected
on the CBC checksum to yield 3 DES keys. If the result matches a "weak" or "semiweak"
key as described in the DES specification, it is eXclusive-ORed with
the constant 00000000000000F0. Finally, the result is returned as
the key. Pseudocode follows:
string_to_key(string,realm,name) {
odd = 1;
s = string + realm;
for(each component in name) {
s = s + component;
}
tempkey = NULL;
pad(s); /* with nulls to 8 byte boundary */
for(24byteblock in s) {
if(odd == 0) {
odd = 1;
reverse(24byteblock)
}
else odd = 0;
tempkey = tempkey XOR 24byteblock;
}
k1 = every third bit (1,4,7,...) of tempkey
k2 = every third bit (2,5,8,...) of tempkey
k3 = every third bit (3,6,9,...) of tempkey
fixparity(k1,k2,k3);
(key1,key2,key3) = DES3-CBC-check(s,k1,k2,k3);
fixparity(key1);
if(is_weak_key_key(key1))
key1 = key1 XOR 0xF0;
fixparity(key2);
if(is_weak_key_key(key2))
key2 = key2 XOR 0xF0;
fixparity(key3);
if(is_weak_key_key(key3))
key3 = key3 XOR 0xF0;
return(key1 + key2 + key3);
}
Richard Basch
Lehman Brothers, Inc. Email: basch@lehman.com
101 Hudson Street 33rd Flr. Fax: +1-201-524-5828
Jersey City, NJ 07302 Voice: +1-201-524-5049
