Provenance of ffdhe2048.txt

[philpennock]

Folks, could someone please explain the provenance of https://ssl-config.mozilla.org/ffdhe2048.txt and how that value was derived from the RFC?

In Exim, we've received a PR from a mystery source, asking to update our copy of ffdhe2048 to a new value. It appears to match the value which Mozilla provides at the above URL. The value in our code is in "std-crypto.c", almost entirely RFC comments and auto-converted constants: https://git.exim.org/exim.git/blob/HEAD:/src/src/std-crypto.c (currently lines 510-518)
with the tooling I wrote to handle the conversion from RFC form being at https://git.exim.org/exim.git/blob/HEAD:/src/util/gen_pkcs3.c

I've re-run the code against the RFC and things so far look like there's no error on our side, but I don't pretend to be a cryptographer and I might have missed something. Something thunderously stupid which means that I've misconverted all the constants?

It would really help to know exactly how the Mozilla-provided DH params were converted, so that I can compare and contrast to see if and how I've done something wrong.

Thanks.

[tomato42]

The value in the ffdhe2048.txt file comes from RFC7919: https://tools.ietf.org/html/rfc7919#appendix-A.1
the value you have in here: https://git.exim.org/exim.git/blob/HEAD:/src/src/std-crypto.c#l512 is missing the first line of the prime (i.e. it starts with D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE not with FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620)

Side note: I don't know what you use those primes for but group 22, 23 and 24 are known weak parameters, you should basically never use them.

[philpennock]

We provide them as options, they're not default; we recommend people generate their own and always have, but several years back added defaults so that DH would always be available. Originally to IKE23 and then a few years back to parameters which I generated but I added the RFC7919 primes so that if people didn't trust me they could choose something with some public record.

The value I have was generated from the RFC text with a tool and I re-ran it yesterday and thought I got the same result as before, but running it now I get the same value you do. I might be going crazy. It's not that the C form was missing the first line of the prime, since that yields a different PEM result and doesn't pass integrity checks.

Okay, thanks, we'll continue looking into it. Since I can now generate a form which matches yours, there's no issue here.

[tomato42]

It's not that the C form was missing the first line of the prime, since that yields a different PEM result and doesn't pass integrity checks.

huh? I took the embedded PEM and used openssl asn1parse to get the value of the prime, it started with D8B9C583...
but even without that, it's clear it's missing the FFFFFFFF FFFFFFFF part as there was no ////////// in the beginning lines of the PEM