Subject: DH key -> symmetric key proposal 2

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 19 Oct 2004 20:11:16 -0700

Brian,

Paul and I worked out this proposal together.  Texts were added on how
to
Select a H().

===============================================================
The KDC reply key is derived as follows:
 
1) Both the KDC and the client calculate the shared secret value 

          DHKey = g^(ab) mod p 

   where a and b are the client's and KDC's private exponents,
   respectively.  DHKey, padded first with leading zeros if necessary  
   to make it the length of the modulus p, is represented as a string 
   of octets in big endian order (such that the size of DHKey in octets 
   is the size of the modulus p).  

2) Let K be the key-generation seed length [6] of the reply key whose
   enctype is selected according to [1].  

3) Let's define function octetstring2key() as follows:
 
   octetstring2key(h, x) == random-to-key(K-truncate(
                                            h(0x00 | x) |
                                            h(0x01 | x) |
                                            h(0x02 | x) | 
                                            ...)))

   where x is an octet string, h(octet string) -> (octet string) is a
   cryptographically strong hash function, | is concatenation; 0x00,
   0x01, and 0x02, etc. are each represented as a single octet;
   random-to-key() is an operation that generates a protocol key from a
   bitstring of length K.  Both K and random-to-key() are defined in 
   the kcrypto profile [6] for the enctype of the reply key.  
   K-truncate() truncates its input to K bits.  
   
   A good example of h() is SHA1.  

4) Let's define H as a hash function based on operations of a given 
   checksum type [6], as follows: 

       H(x) == get_mic(dummy-key, x)
 
   where x is an octet string. 

   H() MUST be a cryptographically strong hash, in order to be suitable 
   for use in the octetstring2key() operation above.  

5) The client specifies a checksum type to use in paChecksum of
   PKAuthenticator.  If the H() operation based on this checksum type 
   is not suitable for use in octetstring2key(), or this checksum type 
   is too weak or not supported by the KDC, the KDC MUST return error 
   code KDC_ERR_PA_CKSUMTYPE_NOT_ACCEPTED(77).  The accompanying 
   e-data for this error is a SEQUENCE OF TYPED-DATA: the data-type is
   TD-UNKEYED-CHECKSUM-INFO (109), and the data-value is an OCTET 
   STRING containing the DER encoding of 

     UNKEYED-CHECKSUM-INFO ::= SEQUENCE OF SEQUENCE {
         cksumtype       [0] Int32,
         ...
     }
 
   This list is in the preference order (favorite choice first) of the
   KDC, and the client SHOULD retry with the first available checksum 
   type.  

6) When cached DH parameters are used, let n_c be the clientDHNonce,
   and n_k be the serverDHNonce; otherwise, let both n_c and n_k 
   be empty octet strings.
 
7) The reply key k is
 
         k = octetstring2key(H, DHKey | n_c | n_k)

   where H() is the hash function based on the checksum type used in 
   in paChecksum of PKAuthenticator (as defined in step 4).

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Oct 2004 12:26:18 -0400

I'm happy with this proposal.  I suspect you probably are not if you
think it through though.  Saying that h is a cryptographically strong
hash says very little about whetherh has structure.

I actually recommend that you say something like h must be a
cryptographically strong hash suitable for use by section 4.5 of RFC
3766.