[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: