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

Re: representation of IKE DH shared secret


Here is my concerns and two pennies worth of a write up:

Security Concerns:
After the Diffie-Hellman key exchange phases are complete, the shared secret is an integer in the DH group as pointer out earlier, and that number may or may not be padded with zero, depending on the most significant bit of the exchanged "integer" and the group (namely, the prime p). This puts a restriction on the most significant octet of the exchanged shared integer, since the exchanged integer must be less than the prime. Note that the zero padding comes as an addition to this.

1. The shared integer is in big endian representation. This is DH as identified in PKCS#3.

2. the restriction on the first octet regardless of the zero padding may reveal some of the bits of the shared integer (some of the bits are zero). And yes, this should be a concern when an attack that reduces the exhaustive search space of a DES key from 2^56 to 2^47 is of a concern.

3. Zero padding problem only makes things worse. It adds an entirely known 8 bits in front of the shared integer.

4. For other key exchange (agreement) algorithms (such as MQV or EC version of DH), restrictions may be different. Those should be addressed after such additional algorithms are added. 

Suggestion: (the write up)
Discard octets upto and including the first non-zero octet, and use the remaining octets in the shared integer as the shared secret.

regards,
- Tolga


>>> John Burke <jburke@cylink.com> 4/22/99 14:01:55 >>>
At 06:53 PM 4/21/99 -0700, somebody wrote:
>On Wed, 21 Apr 1999 01:54:47 EDT you wrote
>> 
>> 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.
  [ ... ]
>I'm obviously not enough of a pedant so let me try to be one. Webster says:
>"encode: to convert (as a body of information) from one system of
>communication into another." So if the KE payload was, say, MIME then we
>would have an encoding. The information is not converted into another
>system. It's not an encoding. It's no contradiction.
> 
[ ... ]
>Is this a problem? We seem to have gotten a score (or so) interoperable
>implementations as its written but maybe that's just because a D-H
>secret hasn't been produced yet that began with 8 bits of zero. But
>somehow I doubt it.

I would suggest the attitude showing through in the above does not
contribute to the clearest specs.  As another responder (Tero Kivinen
<kivinen@ssh.fi>) pointed out, some implementors had to go to an
interoperation workshop to discover such things.  The fact that x percent
of twenty people guess right - when not entirely isolated - doesn't make
the spec clear.

On the other hand there is this in the conclusion:

>The way to proceed is to write up some suggested text and send it to
>the list. If no one complains I'll add it to the next rev which will be
 [ ... ]

- John Burke
  Cylink, Sunnyvale, CA
Follow-Ups: