[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
representation of IKE DH shared secret
RFC 2409 (IKE) uses g^xy, the DH shared secret, in several places.
This is a pure number, but it needs to be an octet sequence to be used.
I don't see any place that specifies how to convert from the number to
the numeral. Note that although the numeral never appears on the
wire, it is used in ways that require both parties to use the same
numeral (eg. generating keying info).
It is easy to infer that the numeral would be big endian -- that's the
way we do things. But what length should the numeral have?
Pluto (the FreeS/WAN IKE daemon) has always used as many octets as
were needed. I suspect that a better choice would be to use the
number of octets needed to represent the number of bits in the group
description. These two numbers are probably different roughly one
time in 256 (i.e. there would be a leading 0 octet in the second
representation this often).
For a similar case, that of the KE payload, RFC 2409 does specify the
more about the representation in section 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.
[This doesn't actually say "padded up to be an integral number of
octets", but I assume that this is meant. Should it be stated?]
[This seems to contradict 3.2:
KE is the key exchange payload which contains the public
information exchanged in a Diffie-Hellman exchange. There is no
particular encoding (e.g. a TLV) used for the data of a KE payload.
I think we do have a particular encoding.]
=> I think that RFC 2409 should have specified the representation to
be used for the DH shared secret.
If it is agreed that this is a problem, what is the appropriate way to
deal with it?
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
Follow-Ups: