| commit | 474ddf8ba95f30e69acea37d76b3e671d89381c3 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Feb 11 10:13:32 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Feb 23 15:59:47 2023 +0000 |
| tree | 801ae4e76c69c583cd142a1c4b1db580042d4dce | |
| parent | 788bf74188fd091b7e67f1ff4a5258bec653b1ea [diff] |
Cap the number of ECDSA and DSA sign iterations. When the parameters are incorrect, all assumptions of (EC)DSA fly out the window, including whether the retry loop actually terminates. While ECDSA is broadly used with fixed, named groups, DSA was catastrophically mis-specified with arbitrary parameters being the default and only mode. Cap the number of retries in DSA_do_sign so invalid DSA groups cannot infinite loop, e.g. if the "generator" is really nilpotent. This also caps the iteration count for ECDSA. We do, sadly, support arbitrary curves via EC_GROUP_new_curve_GFp, to help Conscrypt remain compatible with a badly-designed Java API. After https://boringssl-review.googlesource.com/c/boringssl/+/51925, we documented that untrusted parameters are not supported and may produce garbage outputs, but we did not document that infinite loops are possible. I don't have an example where an invalid curve breaks ECDSA, but as it breaks all preconditions, I cannot be confident it doesn't exist, so just cap the iterations. Thanks to Hanno Böck who originally reported an infinite loop on invalid DSA groups. While that variation did not affect BoringSSL, it inspired us to find other invalid groups which did. Thanks also to Guido Vranken who found, in https://github.com/openssl/openssl/issues/20268, an infinite loop when the private key is zero. That was fixed in the preceding CL, as it impacts valid groups too, but the infinite loop is ultimately in the same place, so this change also would have mitigated the loop. Update-Note: If signing starts failing with ECDSA_R_INVALID_ITERATIONS, something went horribly wrong because it should not be possible with real curves. (Needing even one retry has probability 2^-256 or so.) Change-Id: If8fb0157055d3d8cb180fe4f27ea7eb349ec2738 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57228 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
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: