On 14 June 2013 01:55, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 6/12/2013 11:35 PM, Matt Caswell wrote: >> >> 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" >> > > I was not aware of that specific TLS protocol shortcoming, which makes it > difficult to do a lot of things right. > > Are the p values used generally from some list of well known group > parameters or are they completely arbitrary.
In the (as yet unreleased) 1.0.2 there is support for RFC5114 defined DH parameters. These *do* come with a q value. AFAIK there is no support for well known parameters in the released versions - I think they are completely arbitrary. Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
