commit | dd9ee6068667ca58c8d6f1c1cea617fd69452ecf | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Thu May 11 10:12:03 2023 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon May 15 21:51:01 2023 +0000 |
tree | 91e028c1f8c56bf20114e658f29e4ac5254f6cc2 | |
parent | 786554f8f4e8c75bb18c5f91f69b7a328c177618 [diff] |
Reject RSA keys under 512 bits 512-bit RSA was factored in 1999, so this limit barely means anything. But establish some limit now to ratchet in what we can. We'll raise this limit as we clear through further rounds of bad keys in tests. As part of this, I've touched up rsa_test.cc a bit. All the functions that made assumptions on key size now use std::vector with RSA_size. kKey1 and kKey2 were also 512- and 400-bit RSA, respectively. In principle, we could keep kKey1 for now, but the next stage will break it anyway. I've replaced them with kFIPSKey (which was "FIPS-compliant" but actually 1024-bit) and kTwoPrime (remnant of multi-prime RSA, 2048-bit). As neither name makes sense, they're just the new kKey1 and kKey2. I've also switched from string literals to arrays, which avoids the pesky trailing NUL. Sadly, it is a bit more verbose. Maybe we should switch to writing something like: const std::vector<uint8_t> kKey1 = MustDecodeHex("abcdef1234..."); Static initializers don't matter in tests, after all. Update-Note: We no longer accept 511-bit RSA and below. If you run into this, update test keys to more modern sizes as we plan to raise the limit beyond 512-bit RSA in the future. 512-bit RSA was factored in 1999, so keys at or near this limit have been obsolete for a very, very long time. Bug: 607 Change-Id: I13c3366d7e5f326710f1d1b298f4150a4e8e4d78 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59827 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: