Subject: RE: Deriving a symmetric key from the DH key

From: "Paul Leach" <[email-masked]>
Date: Tue, 19 Oct 2004 10:48:19 -0700

No, I didn't agree with this. get_mic is not a hash. A hash may be
embedded in its output, but the presence of other bits (such as sequence
numbers, version numbers, etc) is allowed and I believe common, and if
so makes it not suitable as a hash for creating keys.

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] On Behalf Of Liqiang(Larry) Zhu
> Sent: Tuesday, October 19, 2004 9:44 AM
> To: [email-masked]; [email-masked]
> Subject: Deriving a symmetric key from the DH key
> 
> 
> Brian,
> 
> 
> Sam, Paul, and I came up with this proposal (but if anything here is
> inaccurate,
> I am most responsible). Please include it in your next version.
> 
> 
> 
> ==================================================================
> 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 hash H be the un-keyed checksum for the paChecksum member
>    of PKAuthenticator.  Hash H is the get_mic() operation [6]
>    in the kcrypto profile with a dummy key (only unkeyed
>    checksum crypto-systems are used) for the corresponding
>    kcrypto checksum cryptosystem.
> 
>    H is selected by the client.  H MUST be cryptographically
>    strong, otherwise the KDC MUST return error code
>    KDC_ERR_PA_CHECKSUM_TOO_WEAK (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, the client SHOULD retry with the first available
>    checksum type.
> 
>    Let K be the key-generation seed length [6] of the reply key
>    whose enctype is selected according to [1].
> 
>    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.
> 
>    Then the reply key k is
> 
>    k = random-to-key(K-truncate(H(0x00 | DHKey | n_c | n_k) |
>                                 H(0x01 | DHKey | n_c | n_k) |
>                                 H(0x02 | DHKey | n_c | n_k) |
>                                 ...)))
> 
>    Where | is concatenation;  0x00, 0x01, and 0x02 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.
> ===================================================================
> 
> -- Larry
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Oct 2004 14:07:24 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> No, I didn't agree with this. get_mic is not a hash. A hash
    Paul> may be embedded in its output, but the presence of other
    Paul> bits (such as sequence numbers, version numbers, etc) is
    Paul> allowed and I believe common, and if so makes it not
    Paul> suitable as a hash for creating keys.

Good catch.  *Oops.*