Various Updates #132
Merged
Various Updates #132
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
pi-314159
commented
Jan 19, 2025
pi-314159
commented
- Update to upstream d4b6eb5
- Updated the OID for SecP384r1MLKEM1024
- Modified the upstream commit hash in the README.md
- Bumped the version number
It flags aes_ctr_set_key as having unreachable code in no-asm builds. It is true that there is unreachable code in there, but I'm unclear on why just that function is being flagged. Since we often will no-op our platform codepaths to avoid ifdefs in build configurations that don't want them, such a sensitive warning is not useful. Just turn it off. Fixed: 385161043 Change-Id: I5ed066d6d1d95dcc57a1cac01fad553e9ef4db7d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74607 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]>
Change-Id: I41638aa7a4d00415eda593fe277fed6f768170de Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73928 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: Adam Langley <[email protected]>
Turns out that we need this one too. Change-Id: I9d9d8871f1a45576b1ef812207cb9ae44a376a2c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74509 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: Adam Langley <[email protected]>
We've since added a few more files that don't have a counterpart in OpenSSL, or are named differently from their OpenSSL counterparts. Change-Id: I7057d8b258cb9656924054022654359d11a164f8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74667 Reviewed-by: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]>
OpenSSL ran a "copyright consolidation" process, driven by this script. We will need to modify it slightly because it sometimes sets the year based on OpenSSL's git. Initially, this checks in an unmodified copy of OpenSSL's script. Bug: 364634028 Change-Id: I5acd518a900d9c5bb4ac637c5a3986ddf0b22bd0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74707 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
OpenSSL's "copyright consolidation" script standardizes their various old copyright headers on a new one. In doing so, it recomputed the copyright year as follows: - The end year was always 2016, when they ran the script. - If the file began with an EAY copyright line, that starting year was used. - Otherwise, the start year was ignored and recomputed from version control. This final step will not run in BoringSSL, because we started a new history. Instead, modify the script to simply take the result of the process from the corresponding file in OpenSSL. Bug: 364634028 Change-Id: I6083a398c7d742210d1b67110dda755ba0509f6c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74708 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
We'll simply be picking up the copyright lines from upstream OpenSSL. But since OpenSSL's script ended up changing the years around, this script will let us check which start years changed. (End years in OpenSSL got all rewritten to 2016 in the "copyright consolidation" process, so there's nothing terribly interesting to check.) Bug: 364634028 Change-Id: Id7263b05a98898fe6a6a121af9655ac0857c3ba2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74709 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This applies the OpenSSL "copyright consolidation" process from the following upstream changes: * openssl/openssl@e0a6519 * openssl/openssl@3fb2cf1 * openssl/openssl@ac3d0e1 * openssl/openssl@c2f312f * openssl/openssl@596d6b7 * openssl/openssl@e18cf66 * openssl/openssl@846e33c * openssl/openssl@440e5d8 * openssl/openssl@21dcbeb * openssl/openssl@6286757 * openssl/openssl@4f22f40 * openssl/openssl@d2e9e32 * openssl/openssl@2039c42 * openssl/openssl@b132225 * openssl/openssl@aa6bb13 * openssl/openssl@b6cff31 * openssl/openssl@9e20068 * openssl/openssl@6aa36e8 * openssl/openssl@44c8a5e This was mostly automated, but partially manual. The automated portion can be reproduced by checking OpenSSL to commit 44c8a5e2b9af8909844cc002c53049311634b314, and running the following: git grep -l -E 'Copyright remains Eric Young|Copyright.*The OpenSSL Project\.|Written by.*for the OpenSSL Project' crypto/ decrepit/ include/ ssl/ | grep -v objects.go > files.txt cat files.txt | xargs -n1 perl -i ./util/copyright.pl From there, some years were fixed up manually according to go/openssl-copyright-consolidation-comparison (internal-only). Three files required additional manual fixing: - crypto/ecdh_extra/ecdh_extra.cc - crypto/fipsmodule/ecdh/ecdh.cc.inc - include/openssl/ecdh.h These files have an OpenSSL header, but *after* a different header, so the script does not correctly detect the now redundant OpenSSL header. They were manually modified to remove it. This matches what seems to have been done to crypto/ec/ecdh_ossl.c in OpenSSL's 4f22f40507fea3f272637eb8e00cadf1f34b10d9. Bug: 364634028 Change-Id: I79a559a409ebe2476f2cb8a48a488ac5dd77c90a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74710 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
This allows the script to recreate the new header. Bug: 364634028 Change-Id: Ie399e95f284b0170e8073e60f71806bf16cf48e2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74711 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This imports the following changes from OpenSSL: * openssl/openssl@aa8f3d7 * openssl/openssl@5aba2b6 * openssl/openssl@c80149d See the following links for some related discussion in OpenSSL's repository: * openssl/openssl#3663 * openssl/openssl#3684 * openssl/openssl#3585 (comment) * openssl/openssl#3685 The copyright_summary script may be used to compare this CL. Note there is one change to ecdsa_test.cc to align with OpenSSL. See go/openssl-copyright-consolidation-comparison (internal-only). Bug: 364634028 Change-Id: I987c4e145d2ccd0c32bbf9e7bb2cc69e89019d35 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74712 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This imports openssl/openssl@624265c from upstream OpenSSL. The only part that applies to BoringSSL is x_spki.c. Bug: 364634028 Change-Id: I709ed9765ee78ed35983384b0a472071a3cee4ea Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74713 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Now that the change has been applied, we no longer need these. Bug: 364634028 Change-Id: I2979b62489d640807c6b2568227c015a05af4d4b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74767 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
We have some logic to implicitly define OPENSSL_STATIC_ARMCAP on some platforms. This was being done a hair too late for the NEED_CPUID logic in crypto/internal.h to pick up. I'm not sure why this is only tripping the Android build now. It seems to have been broken for a long while. I put it in the public headers because <openssl/crypto.h> is also sensitive to OPENSSL_STATIC_ARMCAP, so it seems prudent for it to be set all in one place. Change-Id: I53691b018282a71f5d0cb0f6a6c457e1ee4d1df9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74787 Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
These aren't used externally. While I'm here, const-correct PEM_do_header. Really we could have just made these file-local except that PEM_X509_INFO_read_bio does something weird. Bug: 42290574 Change-Id: I455b9c31da0efb854925bbe38797d3c0e221fcdf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74807 Reviewed-by: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This imports upstream's openssl/openssl@6714cb1 Bug: 364634028 Change-Id: I270390f9a0ab8acb5ec508e2c992ccf6b1091a07 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74768 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
There's a lot more we could improve in this function, but fix this particular egregious issue first. Change-Id: Idc4b7f9aa62972293ead4f8534b8461942318e21 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74808 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Adds: * SHA2-512/224, SHA2-512/256 * SHA3-224, SHA3-256, SHA3-384, SHA3-512 See https://pages.nist.gov/ACVP/draft-vassilev-acvp-drbg.html#section-7.4 Change-Id: I3f7d16062096a2c425f230374d44f1b29c95834d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74687 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Bob Beck <[email protected]>
This commit adjusts the ACVP.md documentation for the KDF-counter command to match the implementation. Prior to this the kdf struct in subprocess that dispatches KDF-counter command invocations had a few divergences from the docs: * If the test case has the "Deferred" property set to true, then the key argument provided to the wrapper is empty. * The wrapper is expected to output three values: the input key (since for deferred tests it was generated module-side), the fixed counter data, and the derived key. For deferred tests the returned key is written to the response `KeyIn`. For non-deferred tests the returned key is verified to match the one that was sent to the submodule as a command arg. Change-Id: If266383e279d2222f55975aa3376e8fb134899d7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74727 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Bob Beck <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Add a VAES-optimized AES-GCM implementation that is optimized for AMD
Zen 3 processors, using AVX2 instead of AVX512 / AVX10. With AVX2 only
16 vector registers are available and some instructions are missing,
which is inconvenient and makes the code not easily sharable with the
AVX512 / AVX10 version. However, using VAES still gives a significant
performance improvement, about 80-85% on long messages as shown by the
following tables which show the change in AES-256-GCM throughput in MB/s
on a Zen 3 "Milan" processor for various message lengths in bytes.
Encryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 3955 | 3749 | 3597 | 3054 | 2411 | 2038 |
After | 7128 | 6631 | 5975 | 4788 | 3807 | 2676 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 1757 | 1405 | 856 | 602 | 356 |
After | 1885 | 1430 | 940 | 593 | 381 |
Decryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 3962 | 3774 | 3593 | 2978 | 2510 | 1998 |
After | 7378 | 6836 | 6282 | 4826 | 3868 | 2753 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 1742 | 1428 | 856 | 535 | 383 |
After | 1940 | 1534 | 940 | 573 | 383 |
Change-Id: I583dd6b48b81ab3c6df51bfe8729366cad500537
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74368
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Since there is now a VAES+AVX2 implementation of AES-GCM, and the future
of AVX10/256 is uncertain, disable the AES-GCM functions that use
AVX10/256 (equivalently AVX512 with a maximum vector length of 256
bits). This leaves VAES+AVX2 as the sole 256-bit support for now.
For now this just affects Intel Ice Lake and Tiger Lake (which actually
support AVX512, but where downclocking issues make 256-bit arguably
preferable to 512-bit), where a slight performance loss is seen on long
messages. The following tables compare AES-256-GCM throughput in MB/s
on Ice Lake server for various message lengths:
Encryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 7533 | 6990 | 6220 | 5096 | 4200 | 2702 |
After | 7403 | 6879 | 6236 | 4980 | 4040 | 2868 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 2086 | 1555 | 1031 | 657 | 433 |
After | 2069 | 1635 | 1045 | 667 | 430 |
Decryption:
| 16384 | 4096 | 4095 | 1420 | 512 | 500 |
--------+-------+-------+-------+-------+-------+-------+
Before | 7703 | 7140 | 6524 | 5283 | 4244 | 2990 |
After | 7572 | 7056 | 6494 | 5155 | 4224 | 3073 |
| 300 | 200 | 64 | 63 | 16 |
--------+-------+-------+-------+-------+-------+
Before | 2276 | 1733 | 1070 | 680 | 447 |
After | 2249 | 1743 | 1100 | 692 | 447 |
This change should be reconsidered if AVX10/256 sees widespread support,
as we shouldn't carry forward a restriction to AVX2 unnecessarily.
This change also replaces gcm_init_vpclmulqdq_avx10 with
gcm_init_vpclmulqdq_avx10_512, now instantiated using 512-bit vectors.
Otherwise it would be the only avx10 function left using 256-bit.
Change-Id: I7fd21568482118a2ce7a382e9042b187cd2739f7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74369
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
This imports openssl/openssl@0904e79 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 <[email protected]>
…upstream OpenSSL This imports openssl/openssl@320a812 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 <[email protected]>
…some functions. 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 <[email protected]> Reviewed-by: Bob Beck <[email protected]>
This was another part of OpenSSL's "copyright consolidation" changes. See: https://github.com/openssl/openssl/blob/44c8a5e2b9af8909844cc002c53049311634b314/crypto/bn/asm/x86_64-gcc.c https://github.com/openssl/openssl/blob/44c8a5e2b9af8909844cc002c53049311634b314/crypto/md5/asm/md5-586.pl https://github.com/openssl/openssl/blob/44c8a5e2b9af8909844cc002c53049311634b314/crypto/md5/asm/md5-x86_64.pl Bug: 364634028 Change-Id: I9bb24c94a468ca419936118f4d1e5b3a359e1674 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74887 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Years computed from version control. Bug: 364634028 Change-Id: I949149b156ea24966813f304699869a5ad304c98 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74888 Reviewed-by: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]>
Bug: 364634028 Change-Id: Id26a236e3cc74944111f1ce74e32dbb481c4b309 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74829 Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Change-Id: If398ea31546f7be98abce4362cae1f7c821ff7aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74867 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Bob Beck <[email protected]>
Change-Id: I94077581037372ea658e60b86b05fa977e1c3ac6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74868 Commit-Queue: Bob Beck <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Auto-Submit: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]>
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 <[email protected]> Auto-Submit: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Change-Id: I11469dc8b987d12f737e51f092ff36f30ee74cd8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73847 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 <[email protected]> Reviewed-by: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]>
Change-Id: I752be9b328cd6a444029f6640a2d7feca0e00206 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75307 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: Bob Beck <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Change-Id: I893930a8d23f49968883e4c9b8425ebcc5a2d23b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75007 Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
- Updated the OID for SecP384r1MLKEM1024 - Modified the upstream commit hash in the README.md - Bumped the version number Signed-off-by: PI <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.