[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: representation of IKE DH shared secret
| 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?
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.
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.
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.
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
Follow-Ups:
References: