On 6/1/2013 1:13 AM, Matt Caswell wrote:
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..."
Please beware that RFC2631 is so old it was based on an early draft of
X9.42, which does not match the released standard.
Going back to your original question though, this is not really a
degenerate key check, but a parameter validation check.
It is *exactly* a degenerate public key check. But all degenerate key
checks are technically parameter validation checks.
Additional (non-mandatory in SP 800-56A) checks include the following:
pubkey != g (detects invalid use of private key==1)
pubkey * g != 1 MOD p (detects invalid use of private key == q - 1)
Combined with the mandatory tests:
pubkey != 0 (detects impossible value not matching any private key)
pubkey != 1 (detects invalid use of private key == 0)
pubkey < p (detects impossible values not matching any private key)
pubkey ** q == 1 MOD p (detects impossible values not matching any
private key)
These tests should detect all or most invalid public keys (it will not
detect public keys using a different value for g).
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
So how did you go about getting this stuff FIPS validated in the first
place?
I kind of expected the FIPS validated module to include all those
OpenSSL implemented algorithms which can be subjected to the CMVP,
not some random subset.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
