Subject: RE: static-static DH proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 24 Sep 2004 14:55:56 -0700

1) I thought AES is a MUST.
2) I do not rely on n-fold, that is why I feed the whole g^xy into the
PRF.
 
Sam Hartman wrote:
> I know you can do worse.  So you need to show that
>  your proposal does not end up doing worse.

I can see with all existing/defined PRFs in kcrypto, I am not doing
worse (I can argue with you if you disagree with this one), but I can
not foresee the future. If such PRF is created in the future, the KDC
can just forbid the use of the corresponding enctype with PKINIT.

larry

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

>>>>> "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.

[lzhu]

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

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 24 Sep 2004 18:11:45 -0400

> 1) I thought AES is a MUST.

For the moment.  If Something Bad happens, like AES gets broken in six 
months, and we come up with a new cryptosystem based on CCM mode or 
something and not using the simplified profile, then Kerberos 5.3 might 
not require an n-fold implementation.

> 2) I do not rely on n-fold, that is why I feed the whole g^xy into the

You're using it to generate the key for calling the PRF, aren't you?

We don't have a lot of analysis at this point in terms of how the 
secrecy or entropy of the result should or does relate to the inputs 
for compliant Kerberos cryptosystem PRFs in general.

> can just forbid the use of the corresponding enctype with PKINIT.

That seems like a poor way to approach it.  The spec for the PRF should 
indicate what properties it should have (and maybe we should've done a 
better job of that?), and the use of the PRF in PKINIT or anything else 
should be based on those properties, not based on additional properties 
inferred from examination of all existing instances at a given point in 
time.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Sep 2004 18:26:55 -0400

AEs is a must.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Sep 2004 18:37:09 -0400

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

    Liqiang(Larry)> 1) I thought AES is a MUST.  

O, you're talking about available of the implementation?  Nothing
guarantees that internals of simplified profile support will be
available to a preauth plugin.

In our implementation the preauth would in fact be able to get to
n_fold fairly easily but that is not guaranteed.