On 12 June 2013 21:15, Jakob Bohm <jb-open...@wisemo.com> wrote: >>> >>>> 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. >
>From "User Guide for the OpenSSL FIPS Object Module v2.0": "Only the algorithms listed in tables 4a and 4b of the Security Policy are allowed in FIPS mode. Note that Diffie-Hellman and RSA are allowed in FIPS mode for key agreement and key establishment even though they are “Non-Approved” for that purpose ...snip... The version of DH used by TLS is a variant on PKCS#3 and not the X9.42 specification, and hence is not compliant with SP800-56A. For example, the requirement: Each private key shall be unpredictable and shall be generated in the range [1, q-1] using an Approved random bit generator. For TLS clients that requirement cannot be satisfied as stated because the parameter "q" is not sent from server to client, only the parameter "p". Clients generate a private key in the range [1, p-1] instead" Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
