Check DSA size limits in a couple more places

This change was prompted by CVE-2024-4603, but is *not* part of it.
BoringSSL is not affected by CVE-2024-4603.

When applications use DSA they are expected to use known-valid domain
parameters (as required by FIPS 186-4, section 4.3). If the application
instead allows the attacker to supply domain parameters, DSA is no
longer cryptographically sound, and algorithms that were otherwise
correct now become DoS attack surfaces.

Alas, incorrect uses of DSA, like Diffie-Hellman (see CVE-2023-3446 and
CVE-2023-3817) are rampant, so it is useful to bound our operations, so
we at least can say something coherent about DoS in this scenario, even
though we cannot avoid the application being cryptographically unsound.
To that end, we already check DSA sizes before using the key, however,
we missed a couple of operations:

- DSA_generate_parameters_ex
- DSA_generate_key

The CL adds those too. I would not expect either to have any security
impact as it's quite unlikely for an application to allow attacker
control of the inputs to either function. Still, we ought to check for
completeness' sake. There's no sense in generating parameters or a key
that we know we'll reject.

Ultimately, the problem here is that DSA was a badly-designed primitive.
with a continuum of domain parameters. Experience has shown that such
systems are confusing and applications will often incorrectly treat
domain parameters as part of the key. Modern primitives use a small set
of discrete, named parameter sets, which is far easier to get right. For
this reason, we consider DSA a deprecated, legacy algorithm.

Change-Id: Ib3b5dece32bcb0ac9a795f8222c1c530d9dd91a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68707
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
4 files changed
tree: 4e636fb757e89fc8508db40a8fd7380d8b64a914
  1. .github/
  2. cmake/
  3. crypto/
  4. decrepit/
  5. fuzz/
  6. gen/
  7. include/
  8. pki/
  9. rust/
  10. ssl/
  11. third_party/
  12. tool/
  13. util/
  14. .bazelignore
  15. .bazelrc
  16. .clang-format
  17. .gitignore
  18. API-CONVENTIONS.md
  19. BREAKING-CHANGES.md
  20. BUILD.bazel
  21. build.json
  22. BUILDING.md
  23. CMakeLists.txt
  24. codereview.settings
  25. CONTRIBUTING.md
  26. FUZZING.md
  27. go.mod
  28. go.sum
  29. INCORPORATING.md
  30. LICENSE
  31. MODULE.bazel
  32. MODULE.bazel.lock
  33. PORTING.md
  34. PrivacyInfo.xcprivacy
  35. README.md
  36. SANDBOXING.md
  37. STYLE.md
README.md

BoringSSL

BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.

Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.

Project links:

There are other files in this directory which might be helpful: