[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Dan Harkins <dharkins@xxxxxxxxxxxxxxxxxxx>*Subject*: wording for representation of IKE DH shared secret*From*: "D. Hugh Redelmeier" <hugh@xxxxxxxxxx>*Date*: Sat, 24 Apr 1999 13:59:25 -0400 (EDT)*Cc*: Tero Kivinen <kivinen@xxxxxx>, ipsec@xxxxxxxxxxxxxxxxx*In-reply-to*: <>*Reply-to*: hugh@xxxxxxxxxx*Sender*: owner-ipsec@xxxxxxxxxxxxxxxxx

Dan, Here is a possible wording change for RFC2409. I'm not saying this is better than Tero's, but I think that combining some of the ideas might be useful. The Diffie-Hellman public values g^x and g^y, and the DH shared secret values g^xy MUST be represented as a octet stream either to be transmitted in a KE payload or to be input to a PRF or hashing function. [There are several cases in which these values are fed to a PRF or hash. To make the text more robust, I think it would good to avoid enumerating the cases here. The examples I've noticed are SKEYID, HASH, and IV.] For values from a MODP group, the representation used is base 256, in network order. The number of octets used MUST be the minimum needed to represent corresponding the group modulus (which may be more than is required for the actual value being represented). [I would guess that saying "base 256" is not the accepted way of describing this, but I don't know where the standard network representation for binary numbers is described or how to refer to it.] For values from a Galois Field, ... [I don't know how to say the right thing] This could replace the existing paragraph in 5: The Diffie-Hellman public value passed in a KE payload, in either a phase 1 or phase 2 exchange, MUST be the length of the negotiated Diffie-Hellman group enforced, if necessary, by pre-pending the value with zeros. | From: Tero Kivinen <kivinen@ssh.fi> | I would suggest something like this: | | g^xy is the Diffie-Hellman shared secret. When this value is | included in the SKEYID calculation as a input for prf it MUST | be prepended with zero bits up to 8-bit boundary, so that it has | same length in octects than group prime number p. When this value | is used in the hash calculation it MUST be in network byte order. | | This is how all the interoperable implementations interpret the | current document. I don't think that this catches all the cases where this representation must be used. I hope that this helps, Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253

**References**:**Re: representation of IKE DH shared secret***From:*Tero Kivinen

- Prev by Date:
**Re: representation of IKE DH shared secret** - Next by Date:
**Re: representation of IKE DH shared secret** - Previous by thread:
**Re: representation of IKE DH shared secret** - Next by thread:
**Re: Re: representation of IKE DH shared secret** - Index(es):