[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: representation of IKE DH shared secret
On Fri, 23 Apr 1999 14:16:03 EDT you wrote
> | From: Dan Harkins <dharkins@Network-Alchemy.COM>
>
> | Actually, they get back into the document. The whole thing about
> | padding the KE payload was because of an incident at a bakeoff where
> | someone's D-H public value began with 8 (or more) zeros and
> | was consequently deemed "too short" by others.
> |
> | The fact that this verbage didn't make it into the representation of
> | the D-H secret was an oversight on my part that we're cleaning up now.
> | I figured it was straightforward but it's not.
>
> I'm glad to hear this.
>
> I was going to take a stab at crafting wording changes (as you had
> invited). Do I take it that this is being taken care of?
I was going to use Kivinen's text. Is that acceptable?
> Is there an "issues list" that would give us advance warning about
> what other problems might be known or being addressed? I have to
> admit that I've not kept up with the mailing list.
There's http://www.lounge.org/ike_doi_errata.html.
> I have another spot that I'd like nailed down in RFC 2409 (IKE). It
> is very much related. From Appendix B:
>
> In phase 1, material for the initialization vector (IV material) for
> CBC mode encryption algorithms is derived from a hash of a
> concatenation of the initiator's public Diffie-Hellman value and the
> responder's public Diffie-Hellman value using the negotiated hash
> algorithm. This is used for the first message only. Each message
> should be padded up to the nearest block size using bytes containing
> 0x00. The message length in the header MUST include the length of the
> pad since this reflects the size of the ciphertext. Subsequent
> messages MUST use the last CBC encryption block from the previous
> message as their initialization vector.
>
> This talks about using the public DH value. I'd like it to specify
> that the representation used is identical to that in the KE payload.
OK.
> I've just found code that does not do this (leading zero bytes were
> discarded). I didn't write it, but I can fix it. Unfortunately, it
> is deployed -- knowing this two weeks earlier would have made a big
> difference. Note that this code has lived through more that one
> Bakeoff without discovery.
Which is probably because your D-H public values at the bakeoff never
began with 8 or more zeros. With a good random number as x in g^x mod p
I'd imagine these things would be quite rare.
Dan.
References: