[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: representation of IKE DH shared secret
Tolga Acar writes:
> 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.
> 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.
The Diffie-Hellman secret is never directly used to derive any keys.
It is used as an input of the prf (usually HMAC-MD5/HMAC-SHA1) whose
output is then used to derived the actual keys used in the ISAKMP SA
or IPSEC SA encryption.
So there is no security problems using the zero padded version of the
shared secret in the IKE.
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.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups:
References: