Subject: RE: PKINIT issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 2 Jun 2004 11:16:09 -0700

Sam Hartman wrote:
> Please restrict yourself to the operations defined in kcrypto.  We
convinced ourselves that generating a combine keys > > 
> function was possible with those operations.  I believe kenh has the
notes on this.

The highlight of our proposal is to negotiate the supported hash
algorithms and it does so by leveraging the existing enctype negotiation
thus it does not need new fields in the existing PKINIT messages for the
negotiation, and it will only use operations within the framework of
kcrypto.

I would like to see kenh's notes.

> Actually, wait, doesn't the existing proposal *require* both sides to
contribute randomness to keys?

Can it do so when static-static DH is used? We do not think it would
make sense to require either side to generate the DH domain parameters
more frequently than necessary.

Thanks,

Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, June 02, 2004 11:06 AM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; Brian Tung; [email-masked]
Subject: Re: PKINIT issues

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

    Liqiang(Larry)> Jeffrey Hutzelm wrote:
    >> -- diffie-hellman open issues - Larry Zhu has volunteered to
    >> research this

    Liqiang(Larry)> I would like to explore the options of allowing
    Liqiang(Larry)> both the KDC and clients insert randomness into
    Liqiang(Larry)> the exchanged key, thus enabling static-static DH
    Liqiang(Larry)> key exchange. I am writing up a simpler proposal
    Liqiang(Larry)> for this (simpler than the one I sent over a while
    Liqiang(Larry)> back), to address the complexity issue. I shall be
    Liqiang(Larry)> able to send it out within the next two weeks or
    Liqiang(Larry)> so.

Please restrict yourself to the operations defined in kcrypto.  We
convinced ourselves that generating a combine keys function was possible
with those operations.  I believe kenh has the notes on this.

Actually, wait, doesn't the existing proposal *require* both sides to
contribute randomness to keys?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Jun 2004 15:11:50 -0400

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

    >> Please restrict yourself to the operations defined in kcrypto.
    Liqiang(Larry)> convinced ourselves that generating a combine keys
    Liqiang(Larry)> > >
    >> function was possible with those operations.  I believe kenh
    Liqiang(Larry)> notes on this.

    Liqiang(Larry)> The highlight of our proposal is to negotiate the
    Liqiang(Larry)> supported hash algorithms and it does so by
    Liqiang(Larry)> leveraging the existing enctype negotiation thus
    Liqiang(Larry)> it does not need new fields in the existing PKINIT
    Liqiang(Larry)> messages for the negotiation, and it will only use
    Liqiang(Larry)> operations within the framework of kcrypto.

I will object to anything that uses a hash negotiation since we've
shown that no such negotiation is necessary.

I'm not sure exactly what problem you're trying to solve though.  If I
understood that and understood that a hash was the best/only solution
to that problem I would probably not object.

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 02 Jun 2004 20:24:39 -0400

>I would like to see kenh's notes.

Let me see what I have ...

Ah, yes, we (I think it was more Sam & Ken Raeburn than I) came up with
a reasonable key combination algorithm.

Basically, we use prf and random-to-key from kcrypto.  What we do is
loop calling prf() for each key (call these keys K1 and K2), and a different
string for each key and loop iteration until enough bits are acquired to
get the target key size.  The pseudo-code is as follows:

	count = 0;
	while (bits < required_bits) {
		sprintf(A1, "CombineA%d", count);
		sprintf(A2, "CombineB%d", count);
		R1 += prf(K1, A1);
		R2 += prf(K2, A2);
		count++;
	}

Hopefully this is clear enough.  Anyway, once you get enough random data
in R1 and R2, you truncate the excess and do:

	K3 = random-to-key(R1 ^ R2)

--Ken