[1282] in Kerberos_V5_Development
2 Questions about 3-des/sha/hmac-sha in Kerberos...
daemon@ATHENA.MIT.EDU (HUGO@watson.ibm.com)
Mon Jun 3 19:17:31 1996
Date: Mon, 3 Jun 96 19:15:38 EDT
From: HUGO@watson.ibm.com
To: URI@watson.ibm.com, basch@lehman.com
Cc: krbdev@MIT.EDU
Ref: Your note of 3 June 1996, 17:47:53 EDT (attached)
>
> Understood. Still, what's wrong with the following:
> - auth-key = OneWayFunction(key, "auth");
> - enc-key = OneWayFunction(key, "crypt");
that's the right way to do it.
>
> 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?
Indeed, it depends. No such results are known between SHA and DES
but that's no guarantee for anything.
It is religiously wrong to have dependencies in the keys.
>
> > For "signed" messages... use the 3-des keys as a basis for the
> > hmac-sha key.
>
> I dislike it.
Except if there is any special problem with the above key derivation
proposed by Uri this subject should be seen as over.
>
> > 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".
an important remark.
>
> > 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
even this I don't like (there is no known strength of encrypting a key under
the same key).
>> 2. Hugo... you mentioned that the following might weaken message integrity:
>>
>> 8 byte 160-bit message-sequence
>> 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-sequence).
I interpreted "SHA cksum" as plain SHA, ie, no key involved in the cksum
computation. If what you meant is a keyed-SHA checksum (eg, HMAC-SHA)
that you then encrypt that is fine.
Namely, encryption does not damage the authentication provided by a
HMAC-SHA, but on the other hand, encryption of unkeyed SHA is not not
enough for integrity protection.
As for prepending length you do not need it if you use HMAC.
If you use a different version of keyed SHA (eg, key prepend only)
then you may need the prepended length.
Hugo
