[1276] in Kerberos_V5_Development
2 Questions about 3-des/sha/hmac-sha in Kerberos...
daemon@ATHENA.MIT.EDU (Richard Basch)
Mon Jun 3 15:11:23 1996
Date: Mon, 3 Jun 1996 15:06:49 -0400
To: uri@watson.ibm.com, hugo@watson.ibm.com
Cc: krbdev@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
Given Kerberos' design, it may be difficult to completely separate the
keying material for the encryption and the message integrity.
Two questions:
1. Is the primary attack that we are avoiding by using the same keying
information basically to protect the compromise of data in the other
system if one is compromised? Or are you also considering the
possibility of doing cryptanalysis that utilizes both cryptosystems
using the same keying information to weaken both systems? In either
case, would it be sufficient if I did the following:
For the private messages: use the 3-des keys for CBC encryption
(first doing e-d-e ECB encryption with the keys, and then performing a
CBC operation using each des block - xoring the encrypted block with the
successive block before doing another e-d-e ecb operation).
For "signed" messages... use the 3-des keys as a basis for the
hmac-sha key. If there were a well-defined one-way algorithm to protect
the key such that it could not be reversed, that should suffice in
providing pseudo-independence. I propose simply doing a 3-des CBC
encryption of the key itself to generate the hmac-sha key. I also did
not think that doubly encrypting the key would really be necessary since
we are also assuming that we can fully obtain the key from a breach of
SHA. If that is possible, one must still be able to determine what key
encrypted in itself resulted in that compromised SHA key...
Does this sound reasonable?
Also, this does not preclude the use of alternate keying mechanisms for
similar checksums... I am calling this part of the des3-sha encryption
suite, but if we were to use IDEA or some other system, then there could
be a similar mechanism that generates an appropriate hmac-sha key from
that key.
2. Hugo... you mentioned that the following might weaken message integrity:
8 byte 160-bit message-seq
confounder SHA cksum
... all encrypted using 3-des cbc ([e-d-e ecb] cbc)
(Uri, I know you want the length in here... I believe the default for
Kerberos is to encode the length in the message-seq).
Since SHA is a "crypto-checksum"... is it not designed to retain its
integrity when integrated into other crypto-systems? It is only
intended to avoid attacks where the message-seq is tampered with, such
as switching th order of des-cblocks. Are there weaknesses in SHA that
lend itself to yielding weak checksums if certain attacks are done on
the encrypted message shown above (eg. could an attacker without the
knowledge of the key potentially alter the encrypted message in the parts
containing the message-seq and the SHA field such that the checksum
would still work?) If so, does it not suggest that SHA's computations
are possibly a means of inverting 3-des cbc mode, or that it is not
a strong one-way digest?
Thanks.
--
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
