On 31 May 2013 21:07, Matt Caswell <fr...@baggins.org> wrote:
> On 31 May 2013 16:42, Jakob Bohm <jb-open...@wisemo.com> wrote:
>> Interesting, I don't seem to be able to find code that calls dh_check
>> or equivalent on received DH group parameters, but then the check in
>> that function is too strict in its criteria (for instance, some
>> standards (such as X9.42 and NIST SP 800-56A) require a subgroup of a
>> smaller order than ((large prime minus 1) divided by 2), which would
>> fail the obsolete test for "safe primes" (primes of the form large
>> prime=one plus two times subgroup prime), which was motivated by a
>> property of now obsolete factorization and discrete logarithm methods.
>
As far as I can tell there is no validation of received group
parameters at all (dh_check is not called). I don't have access to
X9.42, but RFC2631 (based on X9.42) simply says "The ASN.1 for DH keys
in [PKIX] includes elements j and validation- Parms which MAY be used
by recipients of a key to verify that the group parameters were
correctly generated..."
Going back to your original question though, this is not really a
degenerate key check, but a parameter validation check.
>
>> As for the DH_check_pub_key() function, checking if pubkey is in the
>> range "two to large prime minus 2, inclusive" is an insufficient check
>> against accepting degenerate keys. For instance NIST SP 800-56A
>> requires the following check for most FIPS certified implementations
>> (they also allow some less practical checks that typically work only
>> for static DH keys or your own keys):
As far as I am aware there is no claim for NIST SP 800-56A compliance
in the new versions
>>
>> Verify that (public key raised to subgroup prime) equals 1 modulo
>> large prime. Note that checking if (public key raised to (large prime minus
>> 1)) equals 1 modulo large prime is pointless, we need the actual
>> subgroup prime for this.
>>
>
> This check exists in 1.0.2 but not earlier (in DH_check):
>
Doh. I retract that. This is just checking that g^q = 1 mod p, not the
public key.
Again though RFC2631 (based on X9.42), simply says:
The following algorithm MAY be used to validate a received public key
y.
1. Verify that y lies within the interval [2,p-1]. If it does not,
the key is invalid.
2. Compute y^q mod p. If the result == 1, the key is valid.
Otherwise the key is invalid.
NISTSP800-56A is stronger and requires both checks, but as noted above
I don't think there is any claim of compliance to this. However,
probably we should be doing this second check anyway.
Matt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
