Merge in complete history from BoringSSL up to 78b3337 #1
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
Now that Miller-Rabin can reject composites faster, we can do fewer trial divisions. Halving the table seems to improve things for RSA-3072 and RSA-4096. I left RSA-2048 alone since measurements with it halved were a bit more of a wash. (Although now that I've left it alone, it's gotten faster, so these numbers are generally noisy.) Before: Did 320 RSA 2048 key-gen operations in 30132984us (10.6 ops/sec) min: 27703us, median: 81774us, max: 375687us Did 84 RSA 3072 key-gen operations in 30166627us (2.8 ops/sec) min: 86961us, median: 322184us, max: 1170392us Did 30 RSA 4096 key-gen operations in 30644802us (1.0 ops/sec) min: 260916us, median: 772364us, max: 2743435us After: Did 345 RSA 2048 key-gen operations in 30103781us (11.5 ops/sec) min: 23359us, median: 75033us, max: 267159us Did 91 RSA 3072 key-gen operations in 30185495us (3.0 ops/sec) min: 72531us, median: 267385us, max: 1119039us Did 38 RSA 4096 key-gen operations in 30473203us (1.2 ops/sec) min: 228529us, median: 720027us, max: 2039681us Change-Id: I52d431347a70572034ced5b7778a2edac8f15173 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38168 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Use the constants when defined. Also OpenSSL uses 0-indexed iteration counts rather than 1-indexed. This likely changed when we tried to align with the 1-indexed FIPS 186-4 algorithm. Also fix the safe prime call. BN_GENCB_call(cb, i, c1 - 1) doesn't make sense since the first parameter should be an event constant. OpenSSL does BN_GENCB_call(cb, 2, c1 - 1). This also doesn't make sense. OpenSSL documents 2 as meaning the prime has been found. That function is interleaving the p and (p-1)/2 checks to save the full iteration count on p if (p-1)/2 is composite anyway. That also doesn't work because the blinding mechanism runs even if the iteration count is 1, so we're actually paying for the blinding four times. Add a TODO to address this. (I can only assume we just never try to generate safe primes. Moreover, we don't even use BN_generate_prime_ex in RSA keygen. Still, that function needs work.) Change-Id: I6f0b7cd10da28484362c92db0c806c1c3045d415 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38169 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
The extension was renamed to just 'early_data' at some point in TLS 1.3's development. Change-Id: I9d1de10aaeb347237b52a226e9533307f5c269ce Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38224 Reviewed-by: Steven Valdez <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This is much more straightforward, and aligns better with what our actual RSA key generation logic does. Change-Id: I45f368b10f42558b91c2d022847505ddab2f7094 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38170 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
The comment says that an "0x" prefix indicates a hex value. However we always passed PRIu64 as the format specifier for |sscanf|, and |sscanf| isn't documented to handle an 0x prefix expect for "i"-family format specifiers. With |PRIu64|, |sscanf| reads any leading "0x" as just zero. Instead, check for "0x" ourselves and use |PRIx64| if found to parse hex values. Change-Id: Id5ed7009d30902022e5ee640e8931bf1431dedc0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38264 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Allows the utility to work on shared libraries. Also, don't printf the output from hex.Dump() as it may contain formatting chars such as %. Change-Id: I3c091436271c132417fd0212955a6575ef57af50 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38244 Reviewed-by: Adam Langley <[email protected]>
This change adds a test to try and prevent errors like b8f760191e. Since it's challenging to test this code, it uses ptrace to capture a trace of the PRNG behaviour and checks that the observed behaviour matches a much smaller model of the code. The model is hopefully easier to read and believe correct. Change-Id: I00b811dc5692e2fbe3dcc16c622d4eb706f16ce0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38265 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>
This path has always had one-too-few “..” elements since the file first appeared, but everyone seems to have lived with it, presumably because /include is in the search path and the compiler tries relative to that. Change-Id: I30006209ad74d064ded5dd2cd34b1f14806dcffe Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38344 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]>
If -ffunction-sections or -fdata-sections is enabled when doing a FIPS shared build, the linker script won't do what's expected and will silently end up including very little (or nothing) in the integrity check. This changes alters the linker script to discard any text or data sections other than the main one, which should make this failure much more obvious. Also, add assertions (that are always enabled) in the module to check that a few obvious things that should be inside the module boundaries actually are. Change-Id: I91178e213a28a7c0c4a38155974e452cd9d558d1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38324 Reviewed-by: Adam Langley <[email protected]>
Change-Id: Idce6c93f5a37e1f05afaa6fb928e15b92d75e911 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38365 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Change-Id: I4e30bc8b8c1bd1215f516a6c89735782cfbf8ef5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38284 Reviewed-by: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]>
The experiment which motivated CECPQ2b has concluded (although the results haven't been published yet) and the SIKE code is causing some issues for gRPC in gprc/grpc#20100. Also, this is code size that takes up space in Android etc. Change-Id: I43b0b8c420f236c0fe9b40bf2517d2fde98495d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38384 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
It looks like the bn_div fuzzer was inadvertently removed from fuzz/'s CMakeLists during an earlier refactor [1]. This change adds it back. [1]: https://boringssl-review.googlesource.com/c/boringssl/+/31324/ Change-Id: I8bb4b224eedff60cc5cd6df7fa39d9c39d499a56 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38424 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
c951e55 added it back in the build, but it should be listed in documentation too. Picked 384 bytes on the assumption that the largest specialisation that we're likely to have is 1024-bit for RSA 2048. Change-Id: I13fb46dceedb7a62616db6a2b39634a0b6fed508 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38444 Commit-Queue: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Upstream did this in 7644a9aef8932ed4d1c3f25ed776c997702982be, so align with them. Add the new OPENSSL_* names and switch all callers witihn the library to match. Keep the old BUF_* names around for compatibility. Note there were two functions where we already had an OPENSSL_* version: OPENSSL_strdup and OPENSSL_strnlen. The former now gains a NULL check to align with BUF_strdup. The latter gets deduplicated; we had two implementations. Change-Id: Ia1cd4527a752fcd62e142ed1e1d7768d323279ba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38425 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Change-Id: I8fbba51ac650c648893fcd21da5c3018cd7810be Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38426 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Node.js recently added an option to override signature algorithms in nodejs/node#29598 which make use of several NIDs and SSL_get_shared_sigalgs. This CL adds NIDs for Ed448 (but does not implement it) and a shim function for SSL_get_shared_sigalgs that simply returns 0. This enables Electron to reduce its patch surface. Change-Id: I833d30b0248ca68ebce4767dd58d5f087fd1e18e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38404 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This addition duplicates the existing break-tests.sh script, but for the Android context. Change-Id: I54d0881e11231770978633f03af4bf9dc228611b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38465 Reviewed-by: David Benjamin <[email protected]>
Adds getter indicating whether HelloRetryRequest was triggered during TLSv1.3 handshake. Change-Id: I84922188ded81ec89259b5f333c80494426759f8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37304 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
These functions are used by Node.js in nodejs/node#26960. BoringSSL does not support EVP_PKEY_RSA_PSS keys, so they always fail. This simplifies building Node with BoringSSL. Change-Id: I81c4cdba8791a60d965bc176d09e5c818153860c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38524 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Change-Id: Ie3e3748cc1eb0e2f66ef052847179deaf0de239b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38544 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Change-Id: I9f29265715a784e0213425935421639d705cbe31 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38565 Reviewed-by: David Benjamin <[email protected]>
C's specification text around pointer arithmetic is buggy and fails to account for empty spans. Empty spans are typically represented as ptr=NULL and len=0, so (T*)NULL + 0 must be defined for ptr + len to reliably work. C++ does not have this bug and specifies this correctly. See https://crbug.com/1019588. This language bug has made its way over to newer versions of UBSan, which enforce this. In the short term, add bogus length checks as a workaround. However, unlike the memcpy language bug, we cannot address this systematically. In the long term, we need to switch libcrypto to building as C++ for a real fix. To test this, update our clang revision to that in https://chromium-review.googlesource.com/c/chromium/src/+/1879890. Note that clang revision was later reverted in Chromium for seemingly unrelated reasons. This newer UBSan also catches a memcpy/OPENSSL_memcpy issue in siphash.c, from the earlier C NULL bug we'd been working around. Bug: chromium:1019588, chromium:1019644 Change-Id: I460e547c8cd740db68da8cc2a3a970276ec92e90 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38584 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]>
Warning alerts do not exist in TLS 1.3, but RFC 8446 section 6.1 continues to define user_canceled as a signal to cancel the handshake, without specifying how to handle it. JDK11 misuses it to signal full-duplex connection close after the handshake. As a workaround, skip user_canceled as in TLS 1.2. This matches NSS and OpenSSL. Bug: b/135941563 Change-Id: I7ef546f1f166741b9f112686c75e6757331948f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38605 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Change-Id: Ia9dda0826787aea4d63536524074e343ff6c87d9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38644 Reviewed-by: Adam Langley <[email protected]> Reviewed-by: Gurleen Grewal <[email protected]> Commit-Queue: Adam Langley <[email protected]>
Update-Note: If calling code does not work with TLS 1.3, the simplest fix is to call SSL_CTX_set_max_proto_version(ctx, TLS1_2_VERSION). Change-Id: Ic99861753dac117c52aea1988a6c4227a32984ca Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38624 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Change-Id: I0da3e2a89cc502563d74dbbbdb0dddacfaaf5f9c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38664 Commit-Queue: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
The quoting in the JSON configuration string was getting a little out of hand. Use a C++ raw string instead. Change-Id: I568672480e967361f8269382f73e3c41bc71a0b7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38665 Commit-Queue: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Thanks to [email protected] for reporting the issue and providing a patch. Bug: 302 Change-Id: I1200a917ef4b791822712feafece19cb21988d55 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38684 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
On older Linux distributions (e.g. Centos 7 which we still use for Conscrypt releases) PTRACE_O_EXITKILL is defined in <linux/ptrace.h> but this can't be included alongside <sys/ptrace.h> due to conflicting defines, so this is the path of least resistance for portability. Could also define this as 0 if undefined, but all distributions seem to use 1<<20, and Centos 7 kernels should have support as they are 3.10 and later and PTRACE_O_EXITKILL was introduced around 3.8. Change-Id: Ib8a6e0dbc62613e30c38a6cc09522c2d7b92577b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38704 Reviewed-by: Adam Langley <[email protected]>
We run some unit tests with multiple threads now. While that makes it no longer deterministic, we should at least be thread-safe. Change-Id: I5d75f2ff1ce76d0b7914cd6ea61bcf640aa085ab Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41184 Commit-Queue: Steven Valdez <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
PMBTokens ends up converting the same point to affine coordinates repeatedly. Additionally, it converts many affine coordinates at once, which we can batch. Introduce an EC_AFFINE type to store affine points and move the inversion to the Jacobian -> affine conversion. This does mean we lose the (negligible) Montgomery reduction optimization in EC_GFp_mont. point_get_affine_coordinates no longer breaks the EC_FELEM abstraction around Montgomery form. Unfortunately, this complicates hardening of the callers not checking return values because EC_AFFINE cannot represent the point at infinity and, due to OpenSSL's API limitations, groups may not have generators available and the generator is not affine at the type level. (EC_AFFINE cannot represent the point at infinity.) Thus this CL: - Tidies up some duplicate code in setting up the generator and ensures it always has Z = 1. - ec_point_set_affine_coordinates hardens against unused results if the generator is configured. But this is ultimately an internal function. - Retains the hardening on the public APIs by adding calls to ec_set_to_safe_point in two places. This CL does not apply the optimization to Trust Tokens, only introduces the EC_AFFINE abstraction. It additionally continues to store EC_POINTs (used in ECDH and ECDSA) in Jacobian form. See https://crbug.com/boringssl/326#c4 for a discussion on why this is tricky. Those protocols are hopefully simple enough that they don't need complexity around inversions. Having an EC_AFFINE type will also be useful for computing custom tables for Trust Token public keys, which gives a nice speedup. Bug: 326 Change-Id: I11b010a33f36a15bac9939351df5205bd35cc665 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41084 Commit-Queue: Steven Valdez <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
Bug: 328 Change-Id: Iaf3ff1bbe2f21c622b974081281848c60a01f142 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40764 Commit-Queue: Steven Valdez <[email protected]> Reviewed-by: David Benjamin <[email protected]>
The DLEQ logic needs to convert many points to affine coordinates at the Hc computations. Rearrange things so the two happen concurrently, which will allow us to batch the inversions. Change-Id: I09bb053788f1555547272bf9af19b54e0fe7c325 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41085 Commit-Queue: Steven Valdez <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
The DLEQ and DLEQOR proofs require converting many Jacobian points to affine, some multiple times. The inversions involved can be batched. This buys us a +5-8% improvement in token issuance speed. issue and finish_issue should each only perform two inversions per token now. We could save an inversion per token by changing the dleq_generate and dleq_verify function signatures, but that would complicate the likely more valuable batched DLEQ(OR) optimization, so I've left those alone. Before: Did 300 TrustToken-Exp0-Batch1 generate_key operations in 2031798us (147.7 ops/sec) Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2093639us (692.1 ops/sec) Did 96 TrustToken-Exp0-Batch1 issue operations in 2044310us (47.0 ops/sec) Did 84 TrustToken-Exp0-Batch1 finish_issuance operations in 2072137us (40.5 ops/sec) Did 12170000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000098us (6084701.8 ops/sec) Did 315 TrustToken-Exp0-Batch1 redeem operations in 2091938us (150.6 ops/sec) Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2004900us (17457.2 ops/sec) Did 308 TrustToken-Exp0-Batch10 generate_key operations in 2067860us (148.9 ops/sec) Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2005706us (68.8 ops/sec) Did 9 TrustToken-Exp0-Batch10 issue operations in 2107753us (4.3 ops/sec) Did 8 TrustToken-Exp0-Batch10 finish_issuance operations in 2193489us (3.6 ops/sec) Did 12046750 TrustToken-Exp0-Batch10 begin_redemption operations in 2000025us (6023299.7 ops/sec) Did 315 TrustToken-Exp0-Batch10 redeem operations in 2091940us (150.6 ops/sec) Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2008851us (17422.9 ops/sec) Did 756 TrustToken-Exp1-Batch1 generate_key operations in 2051005us (368.6 ops/sec) Did 3633 TrustToken-Exp1-Batch1 begin_issuance operations in 2072577us (1752.9 ops/sec) Did 242 TrustToken-Exp1-Batch1 issue operations in 2052091us (117.9 ops/sec) Did 210 TrustToken-Exp1-Batch1 finish_issuance operations in 2058740us (102.0 ops/sec) Did 12477000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000004us (6238487.5 ops/sec) Did 777 TrustToken-Exp1-Batch1 redeem operations in 2084953us (372.7 ops/sec) Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2028286us (17255.9 ops/sec) Did 756 TrustToken-Exp1-Batch10 generate_key operations in 2051178us (368.6 ops/sec) Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2041875us (174.8 ops/sec) Did 23 TrustToken-Exp1-Batch10 issue operations in 2026494us (11.3 ops/sec) Did 20 TrustToken-Exp1-Batch10 finish_issuance operations in 2048478us (9.8 ops/sec) Did 12492000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000053us (6245834.5 ops/sec) Did 777 TrustToken-Exp1-Batch10 redeem operations in 2084956us (372.7 ops/sec) Did 36000 TrustToken-Exp1-Batch10 finish_redemption operations in 2021991us (17804.2 ops/sec) After: Did 315 TrustToken-Exp0-Batch1 generate_key operations in 2046638us (153.9 ops/sec) [+4.2%] Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2087930us (694.0 ops/sec) [+0.3%] Did 105 TrustToken-Exp0-Batch1 issue operations in 2071104us (50.7 ops/sec) [+8.0%] Did 88 TrustToken-Exp0-Batch1 finish_issuance operations in 2023502us (43.5 ops/sec) [+7.3%] Did 11847000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000041us (5923378.6 ops/sec) [-2.7%] Did 315 TrustToken-Exp0-Batch1 redeem operations in 2084116us (151.1 ops/sec) [+0.4%] Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2003732us (17467.4 ops/sec) [+0.1%] Did 315 TrustToken-Exp0-Batch10 generate_key operations in 2046863us (153.9 ops/sec) [+3.3%] Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2000108us (69.0 ops/sec) [+0.3%] Did 10 TrustToken-Exp0-Batch10 issue operations in 2149283us (4.7 ops/sec) [+9.0%] Did 8 TrustToken-Exp0-Batch10 finish_issuance operations in 2046416us (3.9 ops/sec) [+7.2%] Did 12112000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000077us (6055766.9 ops/sec) [+0.5%] Did 315 TrustToken-Exp0-Batch10 redeem operations in 2084427us (151.1 ops/sec) [+0.4%] Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2015111us (17368.8 ops/sec) [-0.3%] Did 777 TrustToken-Exp1-Batch1 generate_key operations in 2029777us (382.8 ops/sec) [+3.9%] Did 3654 TrustToken-Exp1-Batch1 begin_issuance operations in 2093484us (1745.4 ops/sec) [-0.4%] Did 252 TrustToken-Exp1-Batch1 issue operations in 2024557us (124.5 ops/sec) [+5.5%] Did 220 TrustToken-Exp1-Batch1 finish_issuance operations in 2034633us (108.1 ops/sec) [+6.0%] Did 12659000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000112us (6329145.6 ops/sec) [+1.5%] Did 777 TrustToken-Exp1-Batch1 redeem operations in 2073783us (374.7 ops/sec) [+0.5%] Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2050371us (17070.1 ops/sec) [-1.1%] Did 768 TrustToken-Exp1-Batch10 generate_key operations in 2025482us (379.2 ops/sec) [+2.9%] Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2034429us (175.5 ops/sec) [+0.4%] Did 25 TrustToken-Exp1-Batch10 issue operations in 2049293us (12.2 ops/sec) [+7.5%] Did 21 TrustToken-Exp1-Batch10 finish_issuance operations in 2022256us (10.4 ops/sec) [+6.4%] Did 12702000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000015us (6350952.4 ops/sec) [+1.7%] Did 777 TrustToken-Exp1-Batch10 redeem operations in 2072048us (375.0 ops/sec) [+0.6%] Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2024580us (17287.5 ops/sec) [-2.9%] Change-Id: Ia1b09cd14aa8ce0935d18033fb4bd75666a258e9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41086 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
With multi-scalar multiplication, we're stuck pondering the doubling case. But it's fine for trust tokens, because the points are independent and the scalars are uniformly generated and not under attacker control. That means the probability of hitting a double is negligible. (It's equivalent to accidentally finding the discrete log of two independent points.) Before: Did 306 TrustToken-Exp0-Batch1 generate_key operations in 2000725us (152.9 ops/sec) Did 1428 TrustToken-Exp0-Batch1 begin_issuance operations in 2080325us (686.4 ops/sec) Did 105 TrustToken-Exp0-Batch1 issue operations in 2070658us (50.7 ops/sec) Did 88 TrustToken-Exp0-Batch1 finish_issuance operations in 2023864us (43.5 ops/sec) Did 12283000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000063us (6141306.5 ops/sec) Did 315 TrustToken-Exp0-Batch1 redeem operations in 2084451us (151.1 ops/sec) Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2024388us (17289.2 ops/sec) Did 315 TrustToken-Exp0-Batch10 generate_key operations in 2045481us (154.0 ops/sec) Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2022158us (68.2 ops/sec) Did 10 TrustToken-Exp0-Batch10 issue operations in 2148640us (4.7 ops/sec) Did 8 TrustToken-Exp0-Batch10 finish_issuance operations in 2047452us (3.9 ops/sec) Did 12167000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000118us (6083141.1 ops/sec) Did 315 TrustToken-Exp0-Batch10 redeem operations in 2084853us (151.1 ops/sec) Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2014997us (17369.8 ops/sec) Did 777 TrustToken-Exp1-Batch1 generate_key operations in 2034967us (381.8 ops/sec) Did 3612 TrustToken-Exp1-Batch1 begin_issuance operations in 2052618us (1759.7 ops/sec) Did 264 TrustToken-Exp1-Batch1 issue operations in 2084327us (126.7 ops/sec) Did 220 TrustToken-Exp1-Batch1 finish_issuance operations in 2024603us (108.7 ops/sec) Did 12691000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000111us (6345147.8 ops/sec) Did 777 TrustToken-Exp1-Batch1 redeem operations in 2070867us (375.2 ops/sec) Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2019118us (17334.3 ops/sec) Did 798 TrustToken-Exp1-Batch10 generate_key operations in 2090816us (381.7 ops/sec) Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2032751us (175.6 ops/sec) Did 25 TrustToken-Exp1-Batch10 issue operations in 2046353us (12.2 ops/sec) Did 21 TrustToken-Exp1-Batch10 finish_issuance operations in 2015579us (10.4 ops/sec) Did 12695000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000126us (6347100.1 ops/sec) Did 740 TrustToken-Exp1-Batch10 redeem operations in 2032413us (364.1 ops/sec) Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2011564us (17399.4 ops/sec) After: Did 483 TrustToken-Exp0-Batch1 generate_key operations in 2003131us (241.1 ops/sec) [+57.7%] Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2089317us (693.5 ops/sec) [+1.0%] Did 176 TrustToken-Exp0-Batch1 issue operations in 2094210us (84.0 ops/sec) [+65.7%] Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2006750us (73.3 ops/sec) [+68.5%] Did 12217000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000094us (6108212.9 ops/sec) [-0.5%] Did 483 TrustToken-Exp0-Batch1 redeem operations in 2058132us (234.7 ops/sec) [+55.3%] Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2026970us (17267.2 ops/sec) [-0.1%] Did 504 TrustToken-Exp0-Batch10 generate_key operations in 2086204us (241.6 ops/sec) [+56.9%] Did 144 TrustToken-Exp0-Batch10 begin_issuance operations in 2084670us (69.1 ops/sec) [+1.2%] Did 16 TrustToken-Exp0-Batch10 issue operations in 2008793us (8.0 ops/sec) [+71.1%] Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2033577us (6.9 ops/sec) [+76.2%] Did 12026000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000018us (6012945.9 ops/sec) [-1.2%] Did 483 TrustToken-Exp0-Batch10 redeem operations in 2056418us (234.9 ops/sec) [+55.5%] Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2046766us (17100.1 ops/sec) [-1.6%] Did 1239 TrustToken-Exp1-Batch1 generate_key operations in 2060737us (601.2 ops/sec) [+57.5%] Did 3675 TrustToken-Exp1-Batch1 begin_issuance operations in 2085293us (1762.3 ops/sec) [+0.1%] Did 420 TrustToken-Exp1-Batch1 issue operations in 2008121us (209.2 ops/sec) [+65.1%] Did 378 TrustToken-Exp1-Batch1 finish_issuance operations in 2077226us (182.0 ops/sec) [+67.5%] Did 12783000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000134us (6391071.8 ops/sec) [+0.7%] Did 1197 TrustToken-Exp1-Batch1 redeem operations in 2056802us (582.0 ops/sec) [+55.1%] Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2030955us (17233.3 ops/sec) [-0.6%] Did 1260 TrustToken-Exp1-Batch10 generate_key operations in 2095507us (601.3 ops/sec) [+57.5%] Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2029693us (175.9 ops/sec) [+0.2%] Did 42 TrustToken-Exp1-Batch10 issue operations in 2050856us (20.5 ops/sec) [+67.6%] Did 36 TrustToken-Exp1-Batch10 finish_issuance operations in 2027488us (17.8 ops/sec) [+70.4%] Did 12140000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000070us (6069787.6 ops/sec) [-4.4%] Did 1210 TrustToken-Exp1-Batch10 redeem operations in 2079615us (581.8 ops/sec) [+59.8%] Did 34000 TrustToken-Exp1-Batch10 finish_redemption operations in 2052918us (16561.8 ops/sec) [-4.8%] Change-Id: Idd51d7e1d18f3b94edc4105e68fd50b5f44d87cd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41104 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
Several of the Trust Tokens multiplications use repeated points (G, H, and the public keys). We can precompute a 5-bit comb for those points and perform only 1/5th as many doubles in the multiplication. Before: Did 483 TrustToken-Exp0-Batch1 generate_key operations in 2017082us (239.5 ops/sec) Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2086097us (694.6 ops/sec) Did 176 TrustToken-Exp0-Batch1 issue operations in 2089640us (84.2 ops/sec) Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2027924us (72.5 ops/sec) Did 12284000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000151us (6141536.3 ops/sec) Did 483 TrustToken-Exp0-Batch1 redeem operations in 2063241us (234.1 ops/sec) Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2050694us (17067.4 ops/sec) Did 483 TrustToken-Exp0-Batch10 generate_key operations in 2003222us (241.1 ops/sec) Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2000845us (69.0 ops/sec) Did 16 TrustToken-Exp0-Batch10 issue operations in 2010264us (8.0 ops/sec) Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2036137us (6.9 ops/sec) Did 12106000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000126us (6052618.7 ops/sec) Did 483 TrustToken-Exp0-Batch10 redeem operations in 2062366us (234.2 ops/sec) Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2023617us (17295.8 ops/sec) Did 1254 TrustToken-Exp1-Batch1 generate_key operations in 2086776us (600.9 ops/sec) Did 3612 TrustToken-Exp1-Batch1 begin_issuance operations in 2052090us (1760.2 ops/sec) Did 420 TrustToken-Exp1-Batch1 issue operations in 2002421us (209.7 ops/sec) Did 378 TrustToken-Exp1-Batch1 finish_issuance operations in 2078074us (181.9 ops/sec) Did 12843000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000068us (6421281.7 ops/sec) Did 1210 TrustToken-Exp1-Batch1 redeem operations in 2083419us (580.8 ops/sec) Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2023704us (17295.0 ops/sec) Did 1239 TrustToken-Exp1-Batch10 generate_key operations in 2060962us (601.2 ops/sec) Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2031131us (175.8 ops/sec) Did 42 TrustToken-Exp1-Batch10 issue operations in 2045185us (20.5 ops/sec) Did 36 TrustToken-Exp1-Batch10 finish_issuance operations in 2028604us (17.7 ops/sec) Did 12435000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000084us (6217238.9 ops/sec) Did 1176 TrustToken-Exp1-Batch10 redeem operations in 2023934us (581.0 ops/sec) Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2002899us (17474.7 ops/sec) After: Did 875 TrustToken-Exp0-Batch1 generate_key operations in 2028222us (431.4 ops/sec) [+80.2%] Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2097298us (690.9 ops/sec) [-0.5%] Did 207 TrustToken-Exp0-Batch1 issue operations in 2083578us (99.3 ops/sec) [+18.0%] Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2018783us (72.8 ops/sec) [+0.5%] Did 12020250 TrustToken-Exp0-Batch1 begin_redemption operations in 2000036us (6010016.8 ops/sec) [-2.1%] Did 525 TrustToken-Exp0-Batch1 redeem operations in 2077137us (252.8 ops/sec) [+8.0%] Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2006257us (17445.4 ops/sec) [+2.2%] Did 903 TrustToken-Exp0-Batch10 generate_key operations in 2091846us (431.7 ops/sec) [+79.0%] Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2006432us (68.8 ops/sec) [-0.3%] Did 19 TrustToken-Exp0-Batch10 issue operations in 2000665us (9.5 ops/sec) [+19.3%] Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2045846us (6.8 ops/sec) [-0.5%] Did 12124000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000055us (6061833.3 ops/sec) [+0.2%] Did 525 TrustToken-Exp0-Batch10 redeem operations in 2076637us (252.8 ops/sec) [+7.9%] Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2000072us (17499.4 ops/sec) [+1.2%] Did 2142 TrustToken-Exp1-Batch1 generate_key operations in 2031447us (1054.4 ops/sec) [+75.5%] Did 3633 TrustToken-Exp1-Batch1 begin_issuance operations in 2073265us (1752.3 ops/sec) [-0.4%] Did 504 TrustToken-Exp1-Batch1 issue operations in 2043677us (246.6 ops/sec) [+17.6%] Did 378 TrustToken-Exp1-Batch1 finish_issuance operations in 2086624us (181.2 ops/sec) [-0.4%] Did 12548250 TrustToken-Exp1-Batch1 begin_redemption operations in 2000020us (6274062.3 ops/sec) [-2.3%] Did 1281 TrustToken-Exp1-Batch1 redeem operations in 2067790us (619.5 ops/sec) [+6.7%] Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2012117us (17394.6 ops/sec) [+0.6%] Did 2184 TrustToken-Exp1-Batch10 generate_key operations in 2069977us (1055.1 ops/sec) [+75.5%] Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2041930us (174.8 ops/sec) [-0.5%] Did 50 TrustToken-Exp1-Batch10 issue operations in 2063927us (24.2 ops/sec) [+18.0%] Did 36 TrustToken-Exp1-Batch10 finish_issuance operations in 2038115us (17.7 ops/sec) [-0.5%] Did 12693000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000070us (6346277.9 ops/sec) [+2.1%] Did 1281 TrustToken-Exp1-Batch10 redeem operations in 2066940us (619.8 ops/sec) [+6.7%] Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2020506us (17322.4 ops/sec) [-0.9%] Change-Id: Id26600c07401d6567275155aa389839ac0e87013 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41124 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
Bug: 335 Change-Id: Ic22dafbc4ada3af56260bc7213f0078876e56c3d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41244 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
QUIC imposes additional restrictions on when 0-RTT data can be accepted. With this change, a QUIC server configured to support 0-RTT will only accept early data if the transport parameters and application protocol specific context are a byte-for-byte match from the original connection to the 0-RTT resumption attempt. Bug: 295 Change-Id: Ie5d4688d1c9076b49f2131bb66b27c87e2ba041a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41145 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Before: Did 867 TrustToken-Exp1-Batch1 generate_key operations in 1029740us (842.0 ops/sec) Did 1441 TrustToken-Exp1-Batch1 begin_issuance operations in 1021088us (1411.2 ops/sec) Did 200 TrustToken-Exp1-Batch1 issue operations in 1003145us (199.4 ops/sec) Did 154 TrustToken-Exp1-Batch1 finish_issuance operations in 1053858us (146.1 ops/sec) Did 5128000 TrustToken-Exp1-Batch1 begin_redemption operations in 1000076us (5127610.3 ops/sec) Did 517 TrustToken-Exp1-Batch1 redeem operations in 1031054us (501.4 ops/sec) Did 15000 TrustToken-Exp1-Batch1 finish_redemption operations in 1041906us (14396.7 ops/sec) Did 870 TrustToken-Exp1-Batch10 generate_key operations in 1020929us (852.2 ops/sec) Did 154 TrustToken-Exp1-Batch10 begin_issuance operations in 1085963us (141.8 ops/sec) Did 20 TrustToken-Exp1-Batch10 issue operations in 1040995us (19.2 ops/sec) Did 14 TrustToken-Exp1-Batch10 finish_issuance operations in 1009041us (13.9 ops/sec) Did 5138000 TrustToken-Exp1-Batch10 begin_redemption operations in 1000114us (5137414.3 ops/sec) Did 528 TrustToken-Exp1-Batch10 redeem operations in 1026978us (514.1 ops/sec) Did 15000 TrustToken-Exp1-Batch10 finish_redemption operations in 1016920us (14750.4 ops/sec) After: Did 900 TrustToken-Exp1-Batch1 generate_key operations in 1032678us (871.5 ops/sec) [+3.5%] Did 1410 TrustToken-Exp1-Batch1 begin_issuance operations in 1004439us (1403.8 ops/sec) [-0.5%] Did 154 TrustToken-Exp1-Batch1 issue operations in 1068370us (144.1 ops/sec) [-27.7%] Did 121 TrustToken-Exp1-Batch1 finish_issuance operations in 1048767us (115.4 ops/sec) [-21.0%] Did 5179000 TrustToken-Exp1-Batch1 begin_redemption operations in 1000159us (5178176.7 ops/sec) [+1.0%] Did 572 TrustToken-Exp1-Batch1 redeem operations in 1093354us (523.2 ops/sec) [+4.3%] Did 15000 TrustToken-Exp1-Batch1 finish_redemption operations in 1001506us (14977.4 ops/sec) [+4.0%] Did 913 TrustToken-Exp1-Batch10 generate_key operations in 1027546us (888.5 ops/sec) [+4.3%] Did 154 TrustToken-Exp1-Batch10 begin_issuance operations in 1051530us (146.5 ops/sec) [+3.3%] Did 26 TrustToken-Exp1-Batch10 issue operations in 1027599us (25.3 ops/sec) [+31.7%] Did 24 TrustToken-Exp1-Batch10 finish_issuance operations in 1055615us (22.7 ops/sec) [+63.9%] Did 5100000 TrustToken-Exp1-Batch10 begin_redemption operations in 1000201us (5098975.1 ops/sec) [-0.7%] Did 561 TrustToken-Exp1-Batch10 redeem operations in 1072683us (523.0 ops/sec) [+1.7%] Did 15000 TrustToken-Exp1-Batch10 finish_redemption operations in 1006697us (14900.2 ops/sec) [+1.0%] Change-Id: Ibdc08f9d63e62dda14a2cd9e9d8be27c8723675b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40865 Commit-Queue: Steven Valdez <[email protected]> Reviewed-by: David Benjamin <[email protected]>
The input points are all public, so we can use a faster multi-scalar multiplication. This generalizes ec_point_mul_scalar_public to ec_point_mul_scalar_public_batch. To support the batched DLEQ construction, this function takes an arbirarily-length array of points and allocates some temporaries if necessary. First, to confirm that this doesn't affect the basic ECDSA verify case: Before: Did 6324 ECDSA P-384 verify operations in 3069342us (2060.4 ops/sec) After: Did 6324 ECDSA P-384 verify operations in 3063355us (2064.4 ops/sec) [+0.2%] Results for Trust Tokens issue (Exp1) and finish_issuance (both): Before: Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2059145us (71.4 ops/sec) Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2085888us (6.7 ops/sec) Did 357 TrustToken-Exp1-Batch1 issue operations in 2068238us (172.6 ops/sec) Did 286 TrustToken-Exp1-Batch1 finish_issuance operations in 2090932us (136.8 ops/sec) Did 63 TrustToken-Exp1-Batch10 issue operations in 2068201us (30.5 ops/sec) Did 56 TrustToken-Exp1-Batch10 finish_issuance operations in 2064796us (27.1 ops/sec) After: Did 168 TrustToken-Exp0-Batch1 finish_issuance operations in 2058891us (81.6 ops/sec) [+14.3%] Did 16 TrustToken-Exp0-Batch10 finish_issuance operations in 2075742us (7.7 ops/sec) [+14.8%] Did 378 TrustToken-Exp1-Batch1 issue operations in 2067956us (182.8 ops/sec) [+5.9%] Did 336 TrustToken-Exp1-Batch1 finish_issuance operations in 2097757us (160.2 ops/sec) [+17.1%] Did 105 TrustToken-Exp1-Batch10 issue operations in 2069934us (50.7 ops/sec) [+66.5%] Did 88 TrustToken-Exp1-Batch10 finish_issuance operations in 2014621us (43.7 ops/sec) [+61.1%] (This CL doesn't affect other operations.) Change-Id: Ie643b06f44990ab52bf892a007732fde61cdffe5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41285 Reviewed-by: Steven Valdez <[email protected]> Commit-Queue: David Benjamin <[email protected]>
The small P-256 tables currently store 2 * 16 points in Jacobian coordinates, but all the Z values are one, except for the two entries which store infinity. Instead, store only affine coordinates and omit the infinity entries. (We can recover infinity with constant-time selects.) This trims 1152 bytes from the table. Comparing the sizes of the bssl tool (stripped, otherwise debug symbols undo the size gain), the binary is 4096 bytes smaller, but I suspect this is just an artifact of something rounding to page sizes. Along the way, I've scripted the table generation and merged it into a much generalized version of make_p256-x86_64-table.go. As a bonus, by cutting the size of the table we scan, it's faster! (ECDSA verify was already not scanning a table, so that one staying the same is expected.) Before: Did 22302 ECDH P-256 operations in 4009795us (5561.9 ops/sec) Did 62000 ECDSA P-256 signing operations in 4020075us (15422.6 ops/sec) Did 26544 ECDSA P-256 verify operations in 4056526us (6543.5 ops/sec) After: Did 23001 ECDH P-256 operations in 4016544us (5726.6 ops/sec) [+3.0%] Did 66000 ECDSA P-256 signing operations in 4043083us (16324.2 ops/sec) [+5.8%] Did 26544 ECDSA P-256 verify operations in 4051220us (6552.1 ops/sec) [+0.1%] Change-Id: Ie88898fd56e57505e3a325c50bbaf0dc5d42eeb3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41164 Reviewed-by: Steven Valdez <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Before: Did 19655000 SHA-1 (16 bytes) operations in 2000053us (157.2 MB/sec) Did 5112000 SHA-1 (256 bytes) operations in 2000126us (654.3 MB/sec) Did 1280000 SHA-1 (1350 bytes) operations in 2000559us (863.8 MB/sec) Did 229000 SHA-1 (8192 bytes) operations in 2004784us (935.7 MB/sec) Did 116000 SHA-1 (16384 bytes) operations in 2008224us (946.4 MB/sec) After: Did 20506000 SHA-1 (16 bytes) operations in 2000062us (164.0 MB/sec) [+4.3%] Did 5659000 SHA-1 (256 bytes) operations in 2000100us (724.3 MB/sec) [+10.7%] Did 1454000 SHA-1 (1350 bytes) operations in 2000739us (981.1 MB/sec) [+13.6%] Did 255000 SHA-1 (8192 bytes) operations in 2000733us (1044.1 MB/sec) [+11.6%] Did 129000 SHA-1 (16384 bytes) operations in 2009483us (1051.8 MB/sec) [+11.1%] Change-Id: Idaf75e92b2da4d83b597771aca1123f2884d7687 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41284 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This makes clang-format a no-op. (I would not recommend running clang-format on that file. It takes a while.) Change-Id: Ie4bd93340be8fe586e774ce16b5aed1ab626bb0c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41165 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
We weren't actually reducing MAX_BLINDINGS_PER_RSA under TSan. Change-Id: Ib33dc1a1c0312bd3309a64f2600ec4d6e2ec9ddb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41324 Commit-Queue: Steven Valdez <[email protected]> Reviewed-by: Steven Valdez <[email protected]>
a810d82 added calls to OPENSSL_malloc in this file, but openssl/mem.h was missing. Change-Id: I77e19e61e92b1e73702cb3eb93b9c6e22aca9596 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41344 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
If BoringSSL is used in a sandbox without /proc/cpuinfo, we will silently act as if the CPU is missing capabilities, even though getauxval may be available. We use /proc/cpuinfo to work around a missing AT_HWCAP2 and ignore a particular broken CPU. Ignoring the former fails closed, so it's safe to proceed. The latter fails closed, but it is now vanishingly rare (even missing AT_HWCAP2 has largely dropped off), so instead proceed with getauxval. This makes the /proc paths largely optional. Change-Id: Ib198c4f78ccdae874d55669b6a7508dfbeac0f44 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41325 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
The intent is to replace the logic in [0] and allows Chromium to set up the MADV_WIPEONFORK page without increasing sandbox syscall surface. From there we can remove RAND_set_urandom_fd and trim a bit of complexity from the PRNG logic. [0] https://source.chromium.org/chromium/chromium/src/+/master:content/app/content_main_runner_impl.cc;l=333-341;drc=975850fa57e140ec696114477e9416a19f06d29f Change-Id: I9b679e15da551a10302389556c6c77d192be662a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41326 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Change-Id: I9e5c9b016cc0b3b7926df850d470e6367eb9c0bc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41364 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
andrewhop
changed the title
andrew-kaufman
approved these changes
May 19, 2020
justsmth
added a commit
that referenced
this pull request
Mar 1, 2024
### Description of changes: * Android 14 enforces execute-only memory (XOM) as is being requested by our call to [mprotect](https://man7.org/linux/man-pages/man2/mprotect.2.html) * ARM64 Android is the only platform for which we were explicitly enabling XOM. * The process of moving all static/const variables from `.text` to `.rodata` segments [has been started](a4bc612) but is not yet complete. Follow up in CryptoAlg-2360 ### Testing: * Verified locally with Android 14 emulator: ``` 130|emu64a:/data/local/tmp/aws-lc-build $ uname -a Linux localhost 6.6.9-android15-0-g515a956763d8-ab11275718 #1 SMP PREEMPT Thu Jan 4 21:38:14 UTC 2024 aarch64 Toybox emu64a:/data/local/tmp/aws-lc-build $ ./crypto/crypto_test [==========] Running 2420 tests from 127 test suites. [----------] Global test environment set-up. [----------] 2 tests from ABITest [ RUN ] ABITest.SanityCheck [ OK ] ABITest.SanityCheck (0 ms) [ RUN ] ABITest.AArch64 [ OK ] ABITest.AArch64 (1 ms) ... [----------] 120 tests from TrustTokenAllBadKeyTest/TrustTokenBadKeyTest (1990 ms total) [----------] Global test environment tear-down [==========] 2420 tests from 127 test suites ran. (109149 ms total) [ PASSED ] 2418 tests. ``` By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license. --------- Co-authored-by: Andrew Hopkins <[email protected]>
justsmth
added a commit
that referenced
this pull request
Sep 13, 2024
### Description of changes: * This is a starting point for implementing the functionality of `EVP_PKEY_CTX_ctrl_str` for each of the `EVP_PKEY` types. * Adds `OPENSSL_hexstr2buf` which will be needed to parse the HEX-strings that may be passed to `EVP_PKEY_CTX_ctrl_str` ### Testing: * Added test for `OPENSSL_hexstr2buf` By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.
smittals2
added a commit
that referenced
this pull request
Sep 17, 2024
## What's Changed * Use OPENSSL_STATIC_ASSERT which handles all the platform/compiler/C s… by @andrewhop in #1791 * ML-KEM refactor by @dkostic in #1763 * ML-KEM-IPD to ML-KEM as defined in FIPS 203 by @dkostic in #1796 * Add KDA OneStep testing to ACVP by @skmcgrail in #1792 * Updating erroneous documentation for BIO_get_mem_data and subsequent usage by @smittals2 in #1752 * No-op impls for several EVP_PKEY_CTX functions by @justsmth in #1759 * Drop "ipd" suffix from ML-KEM related code by @dkostic in #1797 * Upstream merge 2024 08 19 by @skmcgrail in #1781 * ML-KEM move to the FIPS module by @dkostic in #1802 * Reduce collision probability for variable names by @torben-hansen in #1804 * Refactor ENGINE API and memory around METHOD structs by @smittals2 in #1776 * bn: Move x86-64 argument-based dispatching of bn_mul_mont to C. by @justsmth in #1795 * Check at runtime that the tool is loading the same libcrypto it was built with by @andrewhop in #1716 * Avoid matching prefixes of a symbol as arm registers by @torben-hansen in #1807 * Add CI for FreeBSD by @justsmth in #1787 * Move curve25519 implementations to fips module except spake25519 by @torben-hansen in #1809 * Add CAST for SP 800-56Cr2 One-Step function by @skmcgrail in #1803 * Remove custom PKCS7 ASN1 functions, add new structs by @WillChilds-Klein in #1726 * NASM use default debug format by @justsmth in #1747 * Add KDF in counter mode ACVP Testing by @skmcgrail in #1810 * add support for OCSP_request_verify by @samuel40791765 in #1778 * Fix GitHub/CodeBuild Purge Lambda by @justsmth in #1808 * KBKDF_ctr_hmac FIPS Service Indicator by @skmcgrail in #1798 * Update x509 tool to write all output to common BIO which is a file or stdout by @andrewhop in #1800 * Add ML-KEM to speed.cc, bump AWSLC_API_VERSION to 30 by @andrewhop in #1817 * Add EVP_PKEY_asn1_* functions by @justsmth in #1751 * Improve portability of CI integration script by @torben-hansen in #1815 * Upstream merge 2024 08 23 by @justsmth in #1799 * Replace ECDSA_METHOD with EC_KEY_METHOD and add the associated API by @smittals2 in #1785 * Cherrypick "Add some barebones support for DH in EVP" by @samuel40791765 in #1813 * Add KDA OneStep (SSKDF_digest and SSKDF_hmac) to FIPS indicator by @skmcgrail in #1793 * Add EVP_Digest one-shot test XOFs by @WillChilds-Klein in #1820 * Wire-up ACVP Testing for SHA3 Signatures with RSA by @skmcgrail in #1805 * Make SHA3 (not SHAKE) Approved for EVP_DigestSign/Verify, RSA and ECDSA. by @nebeid in #1821 * Begin tracking RelWithDebInfo library statistics by @andrewhop in #1822 * Move EVP ed25519 function table under FIPS module by @torben-hansen in #1826 * Avoid C11 Atomics on Windows by @justsmth in #1824 * Improve pre-sandbox setup by @torben-hansen in #1825 * Add OCSP round trip integration test with minor fixes by @samuel40791765 in #1811 * Add various PKCS7 getters and setters by @WillChilds-Klein in #1780 * Run clang-format on pkcs7 code by @WillChilds-Klein in #1830 * Move KEM API and ML-KEM definitions to FIPS module by @torben-hansen in #1828 * fix socat integration CI by @samuel40791765 in #1833 * Retire out-of-module KEM folder by @torben-hansen in #1832 * Refactor RSA_METHOD and expand API by @smittals2 in #1790 * Update benchmark documentation in tool/readme.md by @andrewhop in #1812 * Pre jail unit test by @torben-hansen in #1835 * Move EVP KEM implementation to in-module and correct OID by @torben-hansen in #1838 * More minor symbols Ruby depends on by @samuel40791765 in #1837 * ED25519 Power-on Self Test / CAST / KAT by @skmcgrail in #1834 * ACVP ML-KEM testing by @skmcgrail in #1840 * ACVP ECDSA SHA3 Digest Testing by @skmcgrail in #1819 * ML-KEM Service Indicator for EVP_PKEY_keygen, EVP_PKEY_encapsulate, EVP_PKEY_decapsulate by @skmcgrail in #1844 * Add ML-KEM CAST for KeyGen, Encaps, and Decaps by @skmcgrail in #1846 * ED25519 Service Indicator by @skmcgrail in #1829 * Update Allowed RSA KeySize Generation to FIPS 186-5 specification by @skmcgrail in #1823 * Add ED25519 ACVP Testing by @skmcgrail in #1818 * Make EDDSA/Ed25519 POST lazy initalized by @skmcgrail in #1848 * add support for PEM Parameters without ASN1 hooks by @samuel40791765 in #1831 * Add OpenVPN tip of main to CI by @smittals2 in #1843 * Ensure SSE2 is enabled when using optimized assembly for 32-bit x86 by @graebm in #1841 * Add support for `EVP_PKEY_CTX_ctrl_str` - Step #1 by @justsmth in #1842 * Added SHA3/SHAKE XOF functionality by @jakemas in #1839 * Migrated ML-KEM SHA3/SHAKE usage to fipsmodule by @jakemas in #1851 * AVX-512 support for RSA Signing by @pittma in #1273
WillChilds-Klein
added a commit
to WillChilds-Klein/aws-lc
that referenced
this pull request
Jan 8, 2025
This commit adds a [new flavor of RSA Signatures][1]: `RSASSA-PSS`. PSS-padded RSA is described in [RFC 8017 section 8.1][2], with relevant input parameter validation explained in [RFC 3447 section 9.1.1][3]. As with OAEP RSA cipher padding, we mostly rely on AWS-LC to validate message digest support, and explicity forbid anything outside of the SHA family. PSS allows users to specify the length (in bytes) of the randomly generated salt. This value may not be less than 0 (JCE doesn't allow negative salt lengths at all, and AWS-LC reserved them as special flag values), so we enforce a minimum salt length of 0. The maximum is specified in [RFC 3447 section 9.1.1][3], but relies on the key modulus size to determine the maximum length. Since we don't always know the key size when setParameter is called (key is specified on `init*`, and we don't enforce ordering between calls to `setParameter` and `init*`), we assume 2048 bit field size if no key is present. 2048 was selected because it is the smallest field size that is still considered "secure", and if a caller ends up using a smaller key, AWS-LC will detect this and throw an error. We switch the JCE provider for RSASSA-PSS parameterized tests in EvpSignatureTest from BouncyCastle (BC) to [the SunRsaSign provider][6], primarily due to differences in how they handle PSS parameters. SunRsaSign [allows PSS message digest algorithm and MGF digest algorithms to differ][4], while BC [does not][5]. So, in order to test all possible combinations of PSS and MGF digest algorithms, we need to migrate those tests to use SuncJCE as the JCE provider. To increase compatibility accross providers, we allow callers to specify `null` params in calls to `setParameter` (this is [consistent with BC][7], but [not with SunRsaSign][8]. Similarly, we don't require `setParameter` to be called on `RSASSA-PSS` instances before `init*` is called, defaulting to digest algorithms of SHA1 unless otherwise specified. One point where we do diverge from SunRsaSign (but _not_ from BC) is that we throw if callers attempt to update PSS parameters while building or verifying a signature. We forbid this behavior to avoid signature corruption due to digest algorithms being changed while the signature/digest is still being updated. Finally, @jakemas noted [a criticism][9] of PSS described by Peter Gutman, the crux of which is: > Now let's look at what an attacker can do with the above. The > immediately obvious, trivial attack is a hash-substitution attack. > Unlike PKCS aws#1, PSS doesn't encode the hash algorithm used anywhere in > the signature. [...] By changing hashAlgorithm to whatever you like, for > example an algorithm of the same size that you know how to break, you > can forge the signature. Change the hash from SHA-2/256 to Streebog, > Blake2, Keccak, CRC-256, XOR256, whatever you like, PSS won't detect the > change, making it only as strong as the weakest hash algorithm of the > same bit width that the victim will accept. Unfortunately, because PSS is already standardized, there's not much we can do to mitigate this in our impelementation. The main mitigation we employ is to explicitly disallow non-SHA hash functions (e.g. MD5). All SHA-family hash functions are currently believed to be secure for use in PSS (indeed, the oldest, SHA1, is the default for Java) so no immediate threat remains. If SHA1 is deemed insecure for use in PSS at some point in the future, however, we will need to restrict its specification as a PSS parameter. [1]: https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#signature-algorithms [2]: https://datatracker.ietf.org/doc/html/rfc8017#section-8.1 [3]: https://datatracker.ietf.org/doc/html/rfc3447#section-9.1.1 [4]: https://github.com/corretto/corretto-11/blob/f2c5b39cdb2afc9a9101620d14cf34c7448f826d/src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java#L290-L333 [5]: https://github.com/bcgit/bc-java/blob/bc3b92f1f0e78b82e2584c5fb4b226a13e7f8b3b/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/rsa/PSSSignatureSpi.java#L239-L242 [6]: https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunRsaSignProvider [7]: https://github.com/bcgit/bc-java/blob/bc3b92f1f0e78b82e2584c5fb4b226a13e7f8b3b/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/rsa/PSSSignatureSpi.java#L199-L207 [8]: https://github.com/corretto/corretto-11/blob/f2c5b39cdb2afc9a9101620d14cf34c7448f826d/src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java#L292-L294 [9]: https://marc.info/?l=cryptography&m=157345122116408&w=2
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.
Issue #, if available:
N/A
Description of changes:
This merges in the complete history up to 2020-05-14
78b3337a10a7f7b3495b6cb8140a74e265290898.Ran the following:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.