Subject: RE: static-static DH proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 24 Sep 2004 13:31:57 -0700

Sam Hartman wrote:
>  If you can show me that it does not hurt to include all the bits in
the 
> way that you are proposing, you will go a long way to making me feel
comfortable with your proposal.

The main difference is that in your approach

k_dh = random-to-key(K-truncate(g^xy))

And in my approach

k_dh = random-to-key(K-truncate(PRF(random-to-key(K-fold(g^xy)),
g^xy|n_c|n_k)|g^xy))

Can you tell me why you do not fell more comfortable with the later? The
n-fold primitive is used by kcrypto thus there is nothing new (or not
well reviewed) here.

--Larry
-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Friday, September 24, 2004 1:26 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: static-static DH proposal

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu
<[email-masked]> writes:

    Liqiang(Larry)> Sam Hartman wrote:
    >> I don't see why including all the bits of the shared DH key is
    >> safer.

    Liqiang(Larry)> Let me put it into another way, we are creating a
    Liqiang(Larry)> brand new key generation function, and it does not
    Liqiang(Larry)> hurt to include all the bits of the share secret.

If you can show me that it does not hurt to include all the bits in the
way that you are proposing, you will go a long way to making me feel
comfortable with your proposal.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Sep 2004 16:52:32 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> Can you tell me why you do not fell more
    Liqiang(Larry)> comfortable with the later? The n-fold primitive
    Liqiang(Larry)> is used by kcrypto thus there is nothing new (or
    Liqiang(Larry)> not well reviewed) here.

1) implementations of k-fold may not be avaiable to implementations of
   pkinit.  k-fold is only used in the simplified profile so its
   implementation is not guaranteed to be available.  Thus your
   approach does introduce implementation complexity.

2) k-fold is of dubious quality.  We're happy with its uses in the
   simplified profile but it is sort of lossy.  That is it tends to
   have collisions under certain circumstances.  For this reason I'm
   actually a bit concerned about the 3DES string2key algorithm.  The
   simplified profile use is OK because the only property we depend on
   is that different inputs to dk produce different inputs to the
   block cipher.  We've actually checked that happens to be true.  Ken
   can speak more to this point.

3) I'm fairly certain you cannot do better in security than
   truncation.  I know you can do worse.  So you need to show that
   your proposal does not end up doing worse.

--Sam