aboutsummaryrefslogtreecommitdiff
path: root/crypto/dh_extra/dh_asn1.c
AgeCommit message (Collapse)AuthorFilesLines
2023-08-14Consistently reject large p and large q in DHDavid Benjamin1-0/+4
When applications use Diffie-Hellman incorrectly, and use attacker-supplied domain parameters, rather than known-valid ones (as required by SP 800-56A, 5.5.2), algorithms that aren't designed with attacker-supplied parameters in mind become attack surfaces. CVE-2023-3446 and CVE-2023-3817 in OpenSSL cover problems with the DH_check function given large p and large q. This CL adds some fast validity checks to the DH parameters before running any operation. This differs from upstream in a few ways: - Upstream only addressed issues with DH_check. We also check in DH_generate_key and DH_check_pub_key. - For a more consistent invariant, reuse the existing DH modulus limit. Ideally we'd enforce these invariants on DH creation, but this is not possible due to OpenSSL's API. We additionally check some other cheap invariants. This does not impact TLS, or any applications that used Diffie-Hellman correctly, with trusted, well-known domain parameters. Ultimately, that this comes up at all is a flaw in how DH was specified. This is analogous to the issues with ECC with arbitrary groups and DSA, which led to https://github.com/openssl/openssl/issues/20268 CVE-2022-0778, CVE-2020-0601, and likely others. Cryptographic primitives should be limited to a small set of named, well-known domain parameters. Update-Note: Egregiously large or invalid DH p, q, or g values will be more consistently rejected in DH operations. This does not impact TLS. Applications should switch to modern primitives such as X25519 or ECDH with P-256. Change-Id: I666fe0b9f8b71632f6cf8064c8ea0251e5c286bb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62226 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-10-04Make DH opaque.David Benjamin1-0/+1
In doing so, remove some X9.42 placeholder fields, since it's impossible to set them. I switched dh_test.cc to the getters where it was easy, but OpenSSL's new setters are so tedious that I just gave it access to the internal struct. With this, there are now only two public structs (DSA and RSA) that reference CRYPTO_MUTEX. After that's removed, we can stop worrying about pthread_rwlock_t feature flags in the public headers. Update-Note: DH is now an opaque structure. Callers should use accessors instead of accessing fields. Change-Id: Ia53702f8ab58884a90d85718ee26eb03d062d234 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54625 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2020-12-14Move DH code into the FIPS module.Adam Langley1-0/+160
This change also drops ex_data from DH objects. The global would need special handling in the FIPS module, which isn't hard, but just dropping it saves some of the code-size costs of this change and I cannot find any signs of use of this functionality. Change-Id: I984bd70698c2ec329f340d294b3b9ec169cd0c4e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44524 Reviewed-by: David Benjamin <davidben@google.com>