Re: Replacing the EDH SKIP primes

> On 2 Jul 2019, at 09:49, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Jul 02, 2019 at 08:14:25AM +0100, Peter Eisentraut wrote:

>> <paranoia>
>> I was wondering whether the provided binary blob contained any checksums
>> or other internal checks. How would we know whether it contains
>> transposed characters or replaces a 1 by a I or a l? If I just randomly
>> edit the blob, the ssl tests still pass. (The relevant load_dh_buffer()
>> call does get called by the tests.) How can we make sure we actually
>> got a good copy?
>> </paranoia>
>
> PEM_read_bio_DHparams() has some checks on the Diffie-Hellman key, but
> it is up to the caller to make sure that it is normally providing a
> prime number in this case to make the cracking harder, no?

OpenSSL provides DH_check() which we use in load_dh_file() to ensure that the
user is passing a valid prime in the DH file. Adding this to the hardcoded
blob seems overkill though, once the validity has been verified before it being
committed.

> RFC 3526
> has a small formula in this case, which we can use to double-check the
> patch.

A DH param in PEM (or DER) format can be checked with the openssl dhparam tool.
Assuming the PEM is extracted from the patch into a file, one can do:

openssl dhparam -inform PEM -in /tmp/dh.pem -check -text

The prime is returned and can be diffed against the one in the RFC. If you
modify the blob you will see that the check complains about it not being prime.

There is an expected warning in the output however: "the g value is not a
generator” (this is also present when subjecting the PEM for the 2048 MODP in
OpenSSL). From reading RFC2412 which outlines how the primes are generated,
this is by design. In Appendix E:

"Because these two primes are congruent to 7 (mod 8), 2 is a quadratic
residue of each prime. All powers of 2 will also be quadratic
residues. This prevents an opponent from learning the low order bit
of the Diffie-Hellman exponent (AKA the subgroup confinement
problem). Using 2 as a generator is efficient for some modular
exponentiation algorithms. [Note that 2 is technically not a
generator in the number theory sense, because it omits half of the
possible residues mod P. From a cryptographic viewpoint, this is a
virtue.]"

I’m far from a cryptographer, but AFAICT from reading it essentially means that
the RFC authors chose to limit the search space of the shared secret rather
than leaking a bit of it, and OpenSSL has chosen in DH_check() that leaking a
bit is preferrable. (This makes me wonder if we should downgrade the check in
load_dh_file() "codes & DH_NOT_SUITABLE_GENERATOR” to WARNING, but the lack of
reports of it being a problem either shows that most people are just using
openssl dhparam generated parameters which can leak a bit, or aren’t using DH
files at all.)

cheers ./daniel