openbsd/src/lib/libcrypto/dh/dh_check.c, branch OPENBSD_7_9_BASE

DH_check: teach this DoS vector about RFC 7919 primes

2026-01-23T08:32:22+00:00

ok beck

Scapy special for DH_check()

2026-01-23T08:21:52+00:00

The latest release of Scapy calls DH_check() on all the well-known Diffie-Hellman parameters for RFCs 2409, 3526, and 7919. It does this via pyca/cryptography at startup. Every single time. This is obviously very expensive, due to our 64 MR rounds (which are complete overkill now that we have BPSW). Instead of pondering the ideal number of rounds for BPSW with FFDH, simply skip the check if the parameter matches a well-known prime. These are known to be safe primes, so we can skip those super-expensive and pointless checks without any risk. This is only done for the public dh->p parameter. It could be further optimized, but with the follow-up commit adding the RFC 7919 primes this reduces the startup time to what it was before Scapy 2.7.0: < 1s. Reverting from 64 MR rounds to BN_check_primes rounds, we would still have ~8s startup time without this optimization, which isn't great for an interactive tool. Clearly, it's not entirely our fault, it's also Scapy and cryptography that do something ... suboptimal, but I think we're better off if DH_check() isn't a complete DoS vector. If you're using non-standard parameters with FFDH, you deserve it. We could consider adding a flag for non-well-known p and thus making DH_check() indicate failure for candidate primes larger than, say, 4k. https://github.com/pyca/cryptography/issues/14048 ok beck kenjiro

Use err_local.h rather than err.h in most places

2025-05-10T05:54:39+00:00

ok jsing

Remove X9.42 DH rudiments

2024-11-29T15:59:57+00:00

In the unlikely event that we should ever decide to implement this after a quarter century of not needing it, we can readily put this back. Until then this is dead weight. prompted by a question by djm ok jsing

Garbage collect the DH_check*_ex() API

2024-08-30T17:44:56+00:00

This was only needed by the EVP_PKEY_*check() API, which was defanged. So this silly garbage can now go: it translated flags to errors on the error stack so that openssl *check could print ugly errors while DoS-ing the user. ok beck

Fix a minibug in DH_check()

2023-07-24T16:25:02+00:00

Or in the flag, don't overwrite the already set ones. ok jsing

Hide symbols in dh

2023-07-08T15:29:04+00:00

ok tb@

Make internal header file names consistent

2022-11-26T16:08:57+00:00

Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include was fixed manually. discussed with jsing, no objection bcook

Simplify computation of max_pub_key = dh->p - 1.

2022-07-13T18:38:20+00:00

ok jsing

Provide DH_check*_ex and many error codes

2022-01-10T12:00:52+00:00

DH_check{,_pub_key}_ex() wrap their non-ex versions to translate the flags argument of the original functions into OpenSSL errors. For this almost a dozen new error codes need to be added. DH_params_check{,_ex}() is a new version of DH_check that only performs a cheap subset of the checks. They are needed to implement EVP_PKEY_{public,param}_check() (observe the consistent naming) although the actual implementation of EVP_PKEY_param_check() chose to use DH_check_ex(). As far as I can tell, the only raison d'être of the _ex functions and error codes is to spew them to stderr in a couple of openssl(1) commands. This couldn't have been solved differently... These functions will not be exposed publicly. ok inoguchi jsing