Prepare boringssl infra for master->main migration
Change-Id: I331ff76284091278edfc17946728ac3fbaf040bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75327
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This mirrors the callback-based system. If we get an unsolicited
extension, it's nice to say which it was.
Also fix one of the existing ones to remove what seems to have been a
stray colon.
Change-Id: I2a796ea008823fc749eebc3d2d22b94562329b6b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75427
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This does not seem to be used anywhere, and for good reason: it only
works on UTCTime, so it will break with any dates past 2050, which need
GeneralizedTime. We don't have the ASN1_TIME and ASN1_GENERALIZEDTIME
versions. They seem to have been added a bit later.
(If we ever need to add these back, we should probably change the input
type to int64_t, but for now we don't seem to need them at all.)
Update-Note: Removed an unused function.
Change-Id: I23c9f0b41d210f3a44122165331389b30d6ecab0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75408
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The ACVP.md documentation for the acvptool module wrapper commands
described the "RSA/sigGen/<hash>/pkcs1v1.5" and "RSA/sigGen/<hash>/pss"
commands as only being provided the RSA modulus bit-size, but in
practice the command gets both the bit-size and a message. This commit
updates the docs to match.
Change-Id: I63267bca9855acfb6ba770f3d999fbc6939d283e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75127
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The module wrapper I'm testing supports feedback mode KDF w/ HKDF using
an 8 bit counter and no IV. This commit updates the subprocess handling
for the KDF algorithm to support this use-case.
By offering feedback-mode support with empty IV only the diff is quite
minimal. Module wrappers are assumed to use a capability with
both "supportsEmptyIv":true and "requiresEmptyIv":true.
See the NIST KDF ACVP spec for more information:
https://pages.nist.gov/ACVP/draft-celi-acvp-kbkdf.html
Change-Id: I30eb9d0e8bb88c793d05014e4d98e034675f13b6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74747
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
That will convert nonstandard times to posix times.
Change-Id: I7c09a8d4175ee372ab9f3453e02628c303686888
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75167
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I893930a8d23f49968883e4c9b8425ebcc5a2d23b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75007
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
PEM_X509_INFO_read_bio is weird. It decrypts certificates and CRLs, but
not private keys. We had some comments just saying we were trying to
preserve historical (untested) behavior, but I think I've figured out
why. It's so you can inspect a bundle of certs + encrypted keys without
knowing the password. Attempting but failing to decrypt is fatal.
On the flip side, this means that you cannot use this to decrypt the
private key even if you wanted to! This was probably a mistake in
SSLeay, but probably not worth fixing since this function's grouping
behavior doesn't handle certificate chains right anyway.
But we should at least document and test the intended behavior. This
tests that encrypted private keys are left as placeholders, though I
haven't filled in an encrypted certificate or CRL. (The main nuisance
there is assembling a test input because OpenSSL's APIs don't even let
you make them.)
Bug: 387737061
Change-Id: Iebcafdba4924bbcb6298bde24013a508aecc716a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74810
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When the digest is unset, padding may be either RSA_PADDING_NONE or
RSA_PADDING_PKCS1.
If RSA_PADDING_NONE, this becomes raw RSA public and private key
operations, with signature verify comparing the "digest" against the
output of the raw public key operation.
If RSA_PADDING_PKCS1, this treats the "digest" as the raw DigestInfo
structure.
Test both of these, so we don't break them as we move code around. In
doing so, this revealed that verify in these modes, when the "digest"
doesn't match, forgot to add to the error queue. Fix that up.
Bug: 42290606
Change-Id: I3412a633124a12bda6dfebc08896f616b2d268aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75228
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Get this diff out of the way of other changes.
Change-Id: I0f92f99ae6f2cadd70a86a8bc18a5757ab0a7ba0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75287
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
The foo / foo_extra split will make increasingly less sense as we stop
putting public APIs in crypto/fipsmodule. Just call it crypto/foo and
crypto/fipsmodule/foo.
Bug: 42290602
Change-Id: I5143d3edfb768ed7a1aa288ff606f6f13faa9278
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75151
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Add explicit prefetching to the main loop of the new AES-GCM code,
following the same rationale as change
I6312e01ff0da70cc52f09194846b82cc6b69d37a. For now the same prefetch
distance of 512 bytes is used.
Change-Id: Ib57affb414e88675f3a4c8e124728a0cf412bc0a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75267
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is an internal-only primitive, at least for now.
Change-Id: I365d42c9df59894ed131fba139efc7c9bbe0ed35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75107
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Also update deps from BCR while I'm here.
Change-Id: I7afe58655e966ab9e7d1c99d13a9c9f7594af51c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75229
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We can DEPS in individual directories and just run the actual script.
This avoids needing to maintain our own copy, and also means we can
potentially use Chromium's Rust build later. (The Rust update script
pulls in the Clang one.)
We should also be able to unfork vs_toolchain.py, but there's a minor
headache around it ending up in the LUCI copy of depot_tools and not
being cached. Avoiding that seems to require enough fuss that it might
be easier to switch to the windows_sdk recipe module, even if that VS
toolchain isn't updated as frequently.
Change-Id: Icc4ca117d0187b616747711cb563f766cd3f9aba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74889
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I believe nothing uses this anymore.
Bug: 42290412
Change-Id: I8c736570d89393b37efe8d53cef29f887a8762fa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74927
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It's evidently too easy to ignore the return values of these operations.
After all, ignoring allocation failures is the normal pattern in most
C++ code.
Thus this change marks these functions as `nodiscard`. This does require
a few CHECKs in test code, but it also catches one real instance of a
problem.
Change-Id: I24432506283145fc2f459336fe1035cbca27bd4f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75187
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
No types with destructors or anything yet, but let's start getting rid
of the 'goto err's everywhere. I've opportunistically replaced NULL with
nullptr while I'm here, though we should probably just replace that en
masse in the library since even libssl is still a mix.
(For some reason I thought unique_ptr != NULL didn't work because NULL
was the zero literal, but actually unique_ptr != 0 works just fine.)
Change-Id: I8d749b2ef42cc76e0a66a25033ce880be80d2693
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75227
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
May as well get this one out of the way.
Bug: 42290606
Change-Id: Ia67d5fecbdecc458b2c016c7a6563530bf21811a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75247
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Noticed this as I was looking over the CL. May as well.
Bug: 42290600
Change-Id: I9b32829077745ce98beb6f7a77b9d78548500a79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75152
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
freeze_private_key mostly existed to fill in cached values, but it also
would compute iqmp for keygen. Instead, just compute iqmp in keygen.
This does mean we have two places where we might construct mont_p, but
this should make moving the initialization process around a bit cleaner.
This does mean we'll no longer silently fill in a missing iqmp, but I
don't believe this is an externally-visible behavior change.
RSA_set0_crt_params won't let you set iqmp without also setting dmp1 and
dmq1.
Bug: 42290186
Change-Id: Ib625d41e665efaf3b6a068fe9b6eb40b9da8ee29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75150
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
While I'm here, rename mod_exp to rsa_mod_exp_crt. It is specifically
the CRT implementation.
Bug: 42290186
Change-Id: Ie80831f3e1114ba446f73e448e158602abada8be
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75149
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
To consciously change them in the future without accidental breakage.
Change-Id: Id5d073f8781e63cbf6dbb20cc2615e6655b28222
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75129
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There's certainly lots more to rework over time, but here are some easy
ones.
Bug: 42290600
Change-Id: I378cc58d716a3178dbcc3f2a7272ff13f37814ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75209
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CTAD takes care of all of these.
Bug: 42290600
Change-Id: I191c5710f402835d1b50250225edd4e535c7580c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75208
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Callers now all fill in the public modulus and EC group, so we can
compute the sizes directly.
Bug: 42290475
Change-Id: If01b00fd7e3499561a10750bfc5eb44536fb978e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75148
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We can still check the public parts, which we now expect callers to
provide. (Without rsa->n, PSS does not work, and a group-less EC_KEY
tends to break horribly.) Though it's also pretty unlikely anyone is
calling these functions on such keys.
Update-Note: The filled in parts of keys backed by RSA_METHOD and
ECDSA_METHOD will now participate in RSA_check_key and EC_KEY_check_key.
Bug: 42290186
Change-Id: I3ebc952f6adb36e9ff6a6ae8413ef0ecd72ae6b6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75147
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
No need to deal with converting between string literals and Span<const
char> is kind of annoying, and now we just have std::string_view.
Bug: 42290600
Change-Id: Ic6a4de786f77c512a19fcf10ed7a5f8ec7cfbcdb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75207
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Bug: 42290600
Change-Id: I448cc8c2e4cd54b5021b0ee04191852ef466d169
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75087
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit f2394d14d8. Apparently
Conscrypt relies on this function working with UTCTimes with timezone
offsets, even though the resulting GeneralizedTime is one we would never
parse. Something we'll need to go unwind later.
Change-Id: Ibf3ca1f0eaebe422450c47706fe30217da6998f8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75067
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The acvptool supports modules that have an ACVP-AES-GCM algorithm
capability that includes ivGen=internal. For these test vectors
the tool invokes the AES-GCM-randnonce/open and AES-GCM-randnonce/seal
commands.
This commit updates ACVP.md to describe these commands since their
arguments differ slightly from the base AES-GCM/open and AES-GCM/seal
commands used for ivGen=external vectors.
Change-Id: I52d84e2cc721adf1e1d8314b2679db4896f000b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74527
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This commit updates the acvptool subprocess handling to support the
SSH KDF ACVP tests specified in:
https://pages.nist.gov/ACVP/draft-celi-acvp-kdf-ssh.html
These vectors use the algorithm "kdf-components" and the mode "ssh".
Module wrappers that advertise capabilities that include this algo/mode
need to implement two new commands (described in ACVP.md):
1. "SSHKDF/$HASH/client" for deriving client direction keys.
2. "SSHKDF/$HASH/server" for deriving server direction keys.
Both commands take K, H, SessionID and a cipher name as input and return
the IV key, the encryption key, and the integrity key for their
respective direction.
Change-Id: Ib32612222f0bba299c1365b0bd9188a604fd1ead
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74347
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The Proc-Type header starts with a version number. From RFC 1421,
Section 4.6.1.1:
> The "Proc-Type:" field has two subfields, separated by a comma. The
> first subfield is a decimal number which is used to distinguish among
> incompatible encapsulated header field interpretations which may
> arise as changes are made to this standard. Messages processed
> according to this RFC will carry the subfield value "4" to
> distinguish them from messages processed in accordance with prior PEM
> RFCs.
RFC 1421 was an update of RFC 1113, which used X-Proc-Type: 3,ENCRYPTED,
which we do not support. RFC 1040 defined X-Proc-Type: 2 and RFC 989
defined X-Proc-Type: 1,E. As far as I can tell, no other numbers for
Proc-Type have ever existed, and likely never will.
If we were to ever Proc-Type: 5, we currently return failure but forget
to put something on the error queue. It's possible this was originally
done for extensibility, but it just breaks internal invariants. By
returning zero, the callers will treat this as an error anyway. We'll
just confuse code that expects OpenSSL to return an error. Also
OpenSSL's PEM APIs all treat failure to decrypt (e.g. due to unsupported
future cipher) as an error, so we should treat an unsupported future PEM
encryption scheme as an error too.
Change-Id: Ia1f4f6776fea8d8a465a73105bf3ce24a587f26b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74809
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These algorithms depend on `new_uninit`, which was only made stable with
Rust 1.82. To allow consumers to catch up, this change gates
ML-{KEM,DSA} support in `bssl-crypto` behind a (non-default) feature.
Change-Id: I6ffe60560a4dc0f802564c56498f6a0a073d94da
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75027
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
In ASN1_TIME_to_generalizedtime we were already parsing the
input time string to check for validity at the start of the
function. Instead of throwing away the tm we construct to do this,
keep the tm, and just convert the time normally to what we want
after the check instead of messing with the original string.
Change-Id: I32b351abd135b1f9c30b228c09718c5be994187a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74848
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This reverts commit d678fbfb48.
The original change broke Chromium:
```
error[E0725]: the feature `new_uninit` is not in the list of allowed features
--> ../../third_party/boringssl/src/rust/bssl-crypto/src/lib.rs:28:12
|
28 | #![feature(new_uninit)]
| ^^^^^^^^^^
```
Change-Id: I6732a720a5705cfe7b0219b5d9d02a911af0f89a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74987
Auto-Submit: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I think this was not supposed to be checked in. The generate scripts
tend to drop things extra files into an out directory, but for better or
worse, we don't actually end up checking them in. (They're not in the
corresponding files in Chromium.)
Probably these were lying around in the worktree at the time.
Change-Id: Ibc423ce316ecdf2b4b62a4513d228618ff88bc67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74830
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The crate won't build without it anyway, so unconditionally
try and enable it.
Change-Id: Ief8a7dbf8d0af3040b1832424007150987ce654d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74947
Auto-Submit: Pete Bentley <prb@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Bug: 364634028
Change-Id: Id26a236e3cc74944111f1ce74e32dbb481c4b309
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74829
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Years computed from version control.
Bug: 364634028
Change-Id: I949149b156ea24966813f304699869a5ad304c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74888
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This change reimplements some OpenSSL changes based only on the
description of the work in base.h.
Change-Id: I1a8b3d2774216c43ab446aa56b31cbb40d58b29d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74847
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This imports
320a81277e
from upstream OpenSSL.
This causes the following free functions to no longer check for NULL:
* BIO_CONNECT_free
* BUF_MEM_free
* BN_CTX_free
* BN_RECP_CTX_free
* BN_MONT_CTX_free
* BN_BLINDING_free
* X509_STORE_free
* SSL_SESSION_free
(It also causes tls_free to no longer check for NULL, but that check was
unnecessary.)
Bug: 364634028
Change-Id: Ia625039a0a22b0bf368c39d6b8090ca15955f8e4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74828
Reviewed-by: Adam Langley <agl@google.com>
This imports
0904e79a6e
from upstream OpenSSL. The tree intentionally does not compile at this
point.
Bug: 364634028
Change-Id: I39001741cf0db059e76ad4940004a1d57bf8af12
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74827
Reviewed-by: Adam Langley <agl@google.com>
Josip Sokcevic
David Benjamin
Daniel McCarney
Bob Beck
Eric Biggers
Adam Langley
Joe Gardner
Pete Bentley