| commit | e57ab142c0cabf30b6d4e85b8038003cc179716b | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Mar 17 15:40:03 2024 +1000 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Mar 21 03:34:31 2024 +0000 |
| tree | cbccf40f6f618455bfef822f3ba150cb278fca97 | |
| parent | 021ec339112553e3211cdeea98d29fd659d455ef [diff] |
Add some barebones support for DH in EVP
OpenSSH needs this. Features that have been intentionally omitted for
now:
- X9.42-style Diffie-Hellman ("DHX"). We continue not to support this.
Use ECDH or X25519 instead.
- SPKI and PKCS#8 serialization. Use ECDH or X25519 instead. The format
is a bit ill-defined. Moreover, until we solve the serialization
aspects of https://crbug.com/boringssl/497, adding them would put this
legacy algorithm on path for every caller.
- Most of the random options like stapling a KDF, etc. Though I did add
EVP_PKEY_CTX_set_dh_pad because it's the only way to undo OpenSSL's
bug where they chop off leading zeros by default.
- Parameter generation. Diffie-Hellman parameters should not be
generated at runtime.
This means you need to bootstrap with a DH object and then wrap it in an
EVP_PKEY. This matches the limitations of the EVP API in OpenSSL 1.1.x.
Unfortunately the OpenSSL 3.x APIs are unsuitable for many, many
reasons, so I expect when we get further along in
https://crbug.com/boringssl/535, we'll have established some patterns
here that we can apply to EVP_PKEY_DH too.
Change-Id: I34b4e8799afb266ea5602a70115cc2146f19c6a7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67207
Reviewed-by: Theo Buehler <theorbuehler@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@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: