On 6/14/2013 11:12 PM, Matt Caswell wrote:
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.
Note by "Well known" I meant as in "We happen to know that most
installations of Crypto++ while uses these 10 sets, most installations
of OpenSSL 0.9.x these 9 sets, most installations of MS CryptoAPI, these
25 sets etc.", in which case all those could be tabulated and recognized
even though transmitted as actual (p,g) tupples.
P.S.
I would love a response to the open mathematical question in my
suggested workaround code (previous e-mail).
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
