[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: representation of IKE DH shared secret
| From: Tolga Acar <TACAR@novell.com>
| Here is my concerns and two pennies worth of a write up:
This isn't a problem because the g^xy is used as input to a function
that mixes up the entropy. It is pushed through a prf, sometimes more
than once. Look at the SKEYID_* stuff in RFC2409 (IKE) section 5 and
KEYMAT in section 5.5.
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
| 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.
References: