[1281] in Kerberos_V5_Development
Re: 2 Questions about 3-des/sha/hmac-sha in Kerberos...
daemon@ATHENA.MIT.EDU (Uri Blumenthal)
Mon Jun 3 17:48:11 1996
From: Uri Blumenthal <uri@watson.ibm.com>
To: basch@lehman.com (Richard Basch)
Date: Mon, 3 Jun 1996 17:47:53 -0400 (EDT)
Cc: hugo@watson.ibm.com, krbdev@MIT.EDU, uri@watson.ibm.com (Uri Blumenthal)
In-Reply-To: <199606031906.PAA02193@badger.lehman.com> from "Richard Basch" at Jun 3, 96 03:06:49 pm
Reply-To: uri@watson.ibm.com
Richard Basch says:
> Given Kerberos' design, it may be difficult to completely separate the
> keying material for the encryption and the message integrity.
Understood. Still, what's wrong with the following:
- auth-key = OneWayFunction(key, "auth");
- enc-key = OneWayFunction(key, "crypt");
This approach makes "key" safe regardless of which one (or both)
of auth-key and enc-key are compromised (for any reason).
> 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?........
Obviously, this is the biggest concern.
> ..............Or are you also considering the
> possibility of doing cryptanalysis that utilizes both cryptosystems
> using the same keying information to weaken both systems?.....
I suspect the answer here is "it depends"... Hugo?
> .............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).
This is the only safe way of doing 3DES CBC, so you don't seem
to have much choice (:-).
But isn't the issue here what exactly those 3DES key(s) whould be?
I'd like to see an answer to this.
> For "signed" messages... use the 3-des keys as a basis for the
> hmac-sha key.
I dislike it.
> 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.
1. Does any of SHA, MD5, RIPEMD, HAVAL, n-fold+DES_key(key)
fit your definition of "well-defined"?
And of "irreversible"?
2. Even "pseudo" independence should be both ways. In other words,
it is not good enough if encryption key is not "derivable" from
a "sign-key". Neither should a "sign-key" be tractable from the
used-on-the-traffic "enc-key".
> I propose simply doing a 3-des CBC
> encryption of the key itself to generate the hmac-sha key.
No.
Unless you mean 3DES_key(key) - but in this case why
don't you say so? Being specific isn't an expensive
virtue, y'know (:-). [And no, there's nothing really
"obvious" :-]
> 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.
Duble encryption is used also to eliminate possible weak keys
and identity points (zero for single DES).
Also, Never ASS-u-me! (:-)
What if the keys are NOT obtained from SHA output?
> Does this sound reasonable?
Partially.
> 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.
Sure. But why don't you derive both keys from the Krb-supplied one,
so that no matter which key fails (for WHATEVER reasons), there is
no [known, feasible] way to get the other one?
> (Uri, I know you want the length in here... I believe the default for
> Kerberos is to encode the length in the message-seq).
I think I read somewhere that it's better to prepend the length, than
to append it, but I can't find the references, nor recall exactly why
it is so (if it is so :-).
> Since SHA is a "crypto-checksum"... is it not designed to retain its
> integrity when integrated into other crypto-systems?
Probably it is. It certainly looks so...
> Are there weaknesses in SHA that
> lend itself to yielding weak checksums if certain attacks are done on
> the encrypted message shown above........?
Highly unlikely. Hugo?
> ...are possibly a means of inverting 3-des cbc mode..........
3DES is not "non-invertible" - it's just a very strong cipher.
There are [theoretical] attacks against 3DES.
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
