aboutsummaryrefslogtreecommitdiff
path: root/src/crypto
AgeCommit message (Collapse)Author
2025-07-11crypto/rsa: drop contradictory promise to keep PublicKey modulus secretFilippo Valsorda
We claim to treat N as secret (and indeed bigmod is constant time in relation to the modulus) but at the same time we warn that all inputs to VerifyPKCS1v15 and Verify are public: > The inputs are not considered confidential, and may leak through > timing side channels, or if an attacker has control of part of the > inputs. See #67043 (which focuses on the inverse, recovering signatures by controlling the public key input to Verify), and in particular https://github.com/golang/go/issues/67043#issuecomment-2079335804. Stopping the Verify adaptive attack would require significantly more complexity, the kind that has caused vulnerabilities in the past (e.g. CVE-2016-2107). On the other hand, assuming that a public key is confidential is unlikely to work in practice, since it can be recovered from just two valid (message, signature) pairs. See for example https://keymaterial.net/2024/06/15/reconstructing-public-keys-from-signatures/. This comment was introduced in CL 552935, not really due to a need to specify that N was secret, but rather to clarify that E is not (so it could be used in variable-time exponentiation). Change-Id: I6a6a6964f3f8d2dc2fcc13ce938b271c9de9666b Reviewed-on: https://go-review.googlesource.com/c/go/+/687616 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-11crypto/rsa: fix documentation formattingFilippo Valsorda
Change-Id: I6a6a696422f9ab73b9ddee131b17d3c177fefc4e Reviewed-on: https://go-review.googlesource.com/c/go/+/687615 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-07-10crypto/cipher: Fix comment punctuationMarkus Kusano
Change-Id: I7dc086a87d28ab847288eed13f719421420cd004 Reviewed-on: https://go-review.googlesource.com/c/go/+/686997 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-09crypto/tls: empty server_name conf. ext. from serverDaniel McCarney
When a TLS server uses the information from the server_name extension in a client hello, and the connection isn't resuming, it should return an empty server_name extension in its server hello (or encrypted extensions for TLS 1.3). For TLS <1.3 we we do this in doFullHandshake(), by setting the pre-existing serverHelloMsg.serverNameAck bool. We know that the connection isn't resuming based on the context where this function is called. For TLS 1.3, a new encryptedExtensionsMsg.serverNameAck bool is added, and populated as appropriate in sendServerParameters() based on whether the conn was resumed or not. The encryptedExtensionsMsg marshalling is updated to emit the encrypted extension based on that field. These changes allow enabling the ServerNameExtensionServer-* bogo tests that verify both the presence and absence of the server_name extension based on the relevant specifications. Resolves #74282 Updates #72006 Change-Id: I703bc2ec916b50906bdece7b7483a7faed7aa8e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/684795 TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
2025-07-07crypto/rsa: remove another forgotten note to future selfFilippo Valsorda
In CL 226937 I refactored the RSA-PSS implementation, and apparently left behind a note to think a bit harder about whether this bytes.Equal check should be constant time or not. It snuck through code review, so it's 2018 again, no one is worried about pandemics, I have just joined Google, and I am mailing CL 147637 again. Anyway, as discussed in #67043 and documented in CL 587277, the inputs to signature verification functions are not secret, and are allowed to leak through timing side channels. This means an attacker can already compute h (from signature and public key) and h0 (from message hash and public key). What the attacker can't do is produce a signature that yields the correct h (since that requires the private key). Change-Id: I6a6a4656d6255bdad628a94f48f7ea878a304263 Reviewed-on: https://go-review.googlesource.com/c/go/+/685255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-07-01crypto/tls: ensure the ECDSA curve matches the signature algorithmFilippo Valsorda
Change-Id: I6a6a4656c1b47ba6bd652d4da18922cb6b80a8ab Reviewed-on: https://go-review.googlesource.com/c/go/+/675836 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> TryBot-Bypass: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-07-01crypto/ecdsa: fix crypto/x509 godoc linksFilippo Valsorda
Change-Id: I6a6a6964c0e8269305804dc2bb57f13f94f08ed5 Reviewed-on: https://go-review.googlesource.com/c/go/+/685236 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-07-01Revert "crypto/internal/fips140/subtle: add assembly implementation of ↵Keith Randall
xorBytes for arm" This reverts commit de86d02c32f6690391ed79b99d0f763bb06606d5. Reason for revert: Causes unaligned access failures on some arm hardware Change-Id: Ie280d2c9441f584e2a621f929db5a2e1492bed09 Reviewed-on: https://go-review.googlesource.com/c/go/+/685137 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Julian Zhu <jz531210@gmail.com> Reviewed-by: David Chase <drchase@google.com>
2025-06-30crypto/tls: update bogo versionDaniel McCarney
This commit updates the pinned revision of BoringSSL that's used for the BoGo integration test. Doing this requires a few categories of config changes: * ignoring a few new tests for features crypto/tls doesn't implement * ignoring a few new tests that require further investigation/classification, or that already have an associated tracking issue * updating the error map syntax to accommodate the upstream change that allows a one-to-many mapping One code change is required in the shim test process to adjust how we tear down a connection after an error to account for an upstream change in the test runner. Previously, for error conditions we would immediately close the connection when exiting the shim process. We instead need to do this in a multi-step process: 1. Flush any pending TLS writes to surface any alerts the error condition may have generated. 2. Close the write side of the TCP connection to signal we're not writing anymore. 3. Read and discard any pending data from the peer. 4. Close the read side of the TCP connection to fully close the socket. Without doing this unpredictable timing factors may result in spurious test failures where: 1. The runner sends us data that produces an error. 2. We send an alert, and immediately tear down the connection. 3. The runner tries to perform a write, and hits an error because the pipe is closed. 4. The runner fails the test with the pipe write error, before it reads from the connection to see the expected alert. With the new code we instead swallow the unrelated writes and the runner sees our alert after its ignored write when it tries to read from the conn. The alert is the expected test outcome, and so the test passes. This was previously not an issue because the runner was discarding the write errors. Updates #72006 Change-Id: Ib72a1c5e693aac92144696c8bae888d5f3f6c32f Reviewed-on: https://go-review.googlesource.com/c/go/+/683456 Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-06-30crypto/hmac: wrap ErrUnsupported returned by CloneFilippo Valsorda
Updates #69521 Change-Id: I6a6a4656403b9d35d5e4641b5c5c4975f3fa0e43 Reviewed-on: https://go-review.googlesource.com/c/go/+/675555 Reviewed-by: Austin Clements <austin@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-06-20crypto/cipher: fix link to crypto/aesSean Liao
Fixes #74309 Change-Id: I4d97514355d825124a8d879c2590b45b039f5fd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/682596 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-27crypto/tls: enable signature algorithm BoGo tests (and fix two bugs)Filippo Valsorda
The two bugs are very minor: - We were trying to set the ConnectionState CurveID field even if the RSA key exchange was in use - We were sending the wrong alert from TLS 1.2 clients if none of the certificate signature algorithms were supported Change-Id: I6a6a46564f5a9f1a5d44e54fc59a650118ad67d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/675918 Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-23crypto/tls: signature_algorithms in CertificateRequest can't be emptyFilippo Valsorda
Change-Id: I6a6a4656ab97e1f247df35b2589cd73461b4ac76 Reviewed-on: https://go-review.googlesource.com/c/go/+/675917 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-21crypto,hash: add and implement hash.ClonerFilippo Valsorda
Fixes #69521 Co-authored-by: qiulaidongfeng <2645477756@qq.com> Change-Id: I6a6a465652f5ab7e6c9054e826e17df2b8b34e41 Reviewed-on: https://go-review.googlesource.com/c/go/+/675197 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-21crypto/sha3: un-interleave EOR instructionsRoland Shoemaker
Move two EOR instructions out of blocks of RAX and BCAX instructions. This appears to get a teeny performance improvement, and matches what the Linux kernel implementation does. goos: darwin goarch: arm64 pkg: crypto/sha3 cpu: Apple M1 Pro │ sha3-non-interleaved │ sha3-interleaved │ │ sec/op │ sec/op vs base │ Sha3_512_MTU-10 3.122µ ± 2% 3.107µ ± 1% ~ (p=0.382 n=10) Sha3_384_MTU-10 2.266µ ± 7% 2.287µ ± 11% ~ (p=0.424 n=10) Sha3_256_MTU-10 1.770µ ± 5% 1.793µ ± 4% ~ (p=0.353 n=10) Sha3_224_MTU-10 1.675µ ± 1% 1.664µ ± 2% ~ (p=0.210 n=10) Shake128_MTU-10 1.459µ ± 1% 1.446µ ± 1% -0.89% (p=0.000 n=10) Shake256_MTU-10 1.591µ ± 1% 1.597µ ± 1% ~ (p=0.342 n=10) Shake256_16x-10 27.46µ ± 13% 27.58µ ± 1% ~ (p=0.247 n=10) Shake256_1MiB-10 1.269m ± 10% 1.233m ± 1% -2.89% (p=0.000 n=10) Sha3_512_1MiB-10 2.283m ± 2% 2.275m ± 0% ~ (p=0.247 n=10) geomean 11.62µ 11.59µ -0.25% │ sha3-non-interleaved │ sha3-interleaved │ │ B/s │ B/s vs base │ Sha3_512_MTU-10 412.4Mi ± 2% 414.4Mi ± 1% ~ (p=0.393 n=10) Sha3_384_MTU-10 568.3Mi ± 6% 563.2Mi ± 10% ~ (p=0.436 n=10) Sha3_256_MTU-10 727.7Mi ± 4% 718.0Mi ± 4% ~ (p=0.353 n=10) Sha3_224_MTU-10 768.8Mi ± 1% 773.7Mi ± 1% ~ (p=0.218 n=10) Shake128_MTU-10 882.7Mi ± 1% 890.9Mi ± 1% +0.92% (p=0.000 n=10) Shake256_MTU-10 808.9Mi ± 1% 806.2Mi ± 1% ~ (p=0.353 n=10) Shake256_16x-10 569.0Mi ± 11% 566.6Mi ± 1% ~ (p=0.247 n=10) Shake256_1MiB-10 787.9Mi ± 9% 811.3Mi ± 1% +2.97% (p=0.000 n=10) Sha3_512_1MiB-10 438.0Mi ± 2% 439.6Mi ± 0% ~ (p=0.247 n=10) geomean 641.4Mi 643.1Mi +0.26% Change-Id: I5f358d954aeccb91928caa79be96c2902d9ac97e Reviewed-on: https://go-review.googlesource.com/c/go/+/675136 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Hongxiang Jiang <hxjiang@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto/x509: use truncated SHA-256 for SubjectKeyIdFilippo Valsorda
Fixes #71746 Change-Id: I6a6a46568b092933d8ac2039df99ee9f0edf6e56 Reviewed-on: https://go-review.googlesource.com/c/go/+/674477 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-21crypto/tls: reject duplicate TLS 1.3 EncryptedExtensionsDaniel McCarney
When a TLS 1.3 client processes the server's encryptedExtensionsMsg it should reject instances that contain duplicate extension types. RFC 8446 §4.2 says: There MUST NOT be more than one extension of the same type in a given extension block. This update matches enforcement done in the client hello unmarshalling, but applied to the TLS 1.3 encrypted extensions message unmarshalling. Making this change also allows enabling the DuplicateExtensionClient-TLS-TLS13 BoGo test. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d2 Reviewed-on: https://go-review.googlesource.com/c/go/+/673757 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-21crypto/tls: use decode alert for handshake msg unmarshal errDaniel McCarney
Previously if instances of the handshakeMessage interface returned false from unmarshal(), indicating an umarshalling error, the crypto/tls package would emit an unexpected_message alert. This commit changes to use a decode_error alert for this condition instead. The usage-pattern of the handshakeMessage interface is that we switch on the message type, invoke a specific concrete handshakeMessage type's unmarshal function, and then return it to the caller on success. At this point the caller looks at the message type and can determine if the message was unexpected or not. If it was unexpected, the call-sites emit the correct error for that case. Only the caller knows the current protocol state and allowed message types, not the generic handshake decoding logic. With the above in mind, if we find that within the unmarshal logic for a specific message type that the data we have in hand doesn't match the protocol syntax we should emit a decode_error. An unexpected_message error isn't appropriate because we don't yet know if the message is unexpected or not, only that the message can't be decoded based on the spec's syntax for the type the message claimed to be. Notably one unit test, TestQUICPostHandshakeKeyUpdate, had to have its test data adjusted because it was previously not testing the right thing: it was double-encoding the type & length prefix data for a key update message and expecting the QUIC logic to reject it as an inappropriate post-handshake message. In reality it was being rejected sooner as an invalid key update message from the double-encoding and this was masked by the previous alert for this condition matching the expected alert. Finally, changing our alert allows enabling a handful of BoGo tests related to duplicate extensions of the form "DuplicateExtension[Server|Client]-TLS-[TLS1|TLS11|TLS12|TLS13]". One test remains skipped (DuplicateExtensionClient-TLS-TLS13), as it requires additional follow-up. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/673738 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2025-05-21crypto/tls: disable SHA-1 signature algorithms in TLS 1.2Filippo Valsorda
This implements RFC 9155 by removing support for SHA-1 algorithms: - we don't advertise them in ClientHello and CertificateRequest (where supportedSignatureAlgorithms is used directly) - we don't select them in our ServerKeyExchange and CertificateVerify (where supportedSignatureAlgorithms filters signatureSchemesForCertificate) - we reject them in the peer's ServerKeyExchange and CertificateVerify (where we check against the algorithms we advertised in ClientHello and CertificateRequest) Fixes #72883 Change-Id: I6a6a4656e2aafd2c38cdd32090d3d8a9a8047818 Reviewed-on: https://go-review.googlesource.com/c/go/+/658216 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto: add a test for disallowed instructionsRoland Shoemaker
WORD and BYTE usage in crypto assembly cores is an anti-pattern which makes extremely sensitive code significantly harder to understand, and can result in unexpected behavior. Because of this, we've decided to ban their usage in the crypto/ tree (as part of the cryptography assembly policy). This test walks the crypto/ tree looking for assembly files (those with the filetype .s) and look for lines that match the regular rexpression "(^|;)\s(BYTE|WORD)\s". Change-Id: I60b5283e05e8588fa53273904a9611a411741f72 Reviewed-on: https://go-review.googlesource.com/c/go/+/671099 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Roland Shoemaker <roland@golang.org>
2025-05-21crypto/ecdsa: add low-level encoding functions for keysFilippo Valsorda
Fixes #63963 Change-Id: I6a6a4656a729b6211171aca46bdc13fed5fc5643 Reviewed-on: https://go-review.googlesource.com/c/go/+/674475 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-21crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3Filippo Valsorda
If a ClientHello only supports TLS 1.3, or if a CertificateRequest is sent after selecting TLS 1.3, we should not advertise TLS 1.2-only signature_algorithms like PKCS#1 v1.5 or SHA-1. However, since crypto/x509 still supports PKCS#1 v1.5, and a direct CertPool match might not care about the signature in the certificate at all, start sending a separate signature_algorithms_cert extension to indicate support for PKCS#1 v1.5 and SHA-1 in certificates. We were already correctly rejecting these algorithms if the peer selected them in a TLS 1.3 connection. Updates #72883 Change-Id: I6a6a4656ab60e1b7fb20fdedc32604dc156953ae Reviewed-on: https://go-review.googlesource.com/c/go/+/658215 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto/sha3: add SIMD implementation with ARMv8.2 featuresHowJmay
On ARMv8 four SIMD instructions, EOR3, RAX1, XAR, BCAX are added to accelerate sha3 operations. Here the SIMD version of sha3 on ARMv8 is added. fips140: off goos: darwin goarch: arm64 pkg: crypto/sha3 cpu: Apple M2 │ 9e72f5fe60 │ ab93158ba0-dirty │ │ sec/op │ sec/op vs base │ Sha3_512_MTU-8 6.497µ ± 1% 2.988µ ± 0% -54.01% (p=0.002 n=6) Sha3_384_MTU-8 4.639µ ± 5% 2.142µ ± 1% -53.83% (p=0.002 n=6) Sha3_256_MTU-8 3.631µ ± 1% 1.698µ ± 6% -53.24% (p=0.002 n=6) Sha3_224_MTU-8 3.443µ ± 1% 1.602µ ± 1% -53.47% (p=0.002 n=6) Shake128_MTU-8 2.974µ ± 2% 1.392µ ± 1% -53.19% (p=0.002 n=6) Shake256_MTU-8 3.320µ ± 0% 1.537µ ± 2% -53.70% (p=0.002 n=6) Shake256_16x-8 47.26µ ± 1% 27.39µ ± 6% -42.06% (p=0.002 n=6) Shake256_1MiB-8 2.567m ± 1% 1.306m ± 1% -49.12% (p=0.002 n=6) Sha3_512_1MiB-8 4.785m ± 1% 2.397m ± 8% -49.90% (p=0.002 n=6) geomean 23.47µ 11.38µ -51.52% │ 9e72f5fe60 │ ab93158ba0-dirty │ │ B/s │ B/s vs base │ Sha3_512_MTU-8 198.2Mi ± 1% 430.9Mi ± 0% +117.45% (p=0.002 n=6) Sha3_384_MTU-8 277.5Mi ± 5% 601.1Mi ± 1% +116.58% (p=0.002 n=6) Sha3_256_MTU-8 354.6Mi ± 1% 758.2Mi ± 6% +113.85% (p=0.002 n=6) Sha3_224_MTU-8 373.9Mi ± 1% 803.6Mi ± 1% +114.90% (p=0.002 n=6) Shake128_MTU-8 432.9Mi ± 2% 925.2Mi ± 1% +113.70% (p=0.002 n=6) Shake256_MTU-8 387.8Mi ± 0% 837.6Mi ± 2% +115.98% (p=0.002 n=6) Shake256_16x-8 330.6Mi ± 1% 570.7Mi ± 6% +72.61% (p=0.002 n=6) Shake256_1MiB-8 389.5Mi ± 1% 765.5Mi ± 1% +96.53% (p=0.002 n=6) Sha3_512_1MiB-8 209.0Mi ± 1% 417.2Mi ± 8% +99.61% (p=0.002 n=6) geomean 317.7Mi 655.3Mi +106.29% fips140: off goos: darwin goarch: arm64 pkg: crypto/mlkem cpu: Apple M2 │ 9e72f5fe60 │ 257696ed2d-dirty │ │ sec/op │ sec/op vs base │ KeyGen-8 36.97µ ± 1% 29.82µ ± 3% -19.34% (p=0.002 n=6) Encaps-8 51.54µ ± 5% 44.75µ ± 5% -13.17% (p=0.002 n=6) Decaps-8 47.72µ ± 10% 44.73µ ± 1% -6.27% (p=0.002 n=6) RoundTrip/Alice-8 90.47µ ± 2% 79.74µ ± 1% -11.86% (p=0.002 n=6) RoundTrip/Bob-8 52.15µ ± 1% 44.45µ ± 0% -14.76% (p=0.002 n=6) geomean 53.27µ 46.25µ -13.18% Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_15 Co-authored-by: Filippo Valsorda <filippo@golang.org> Change-Id: I8c1f476a7d59498bb44d09d7a573beaa07b10f53 Reviewed-on: https://go-review.googlesource.com/c/go/+/667675 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto/internal/cryptotest: test Armv8.2 on darwin/arm64Filippo Valsorda
Fixes #69593 Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_15 Change-Id: I6a6a4656302d65b582df582fa12bb72b88b0316d Reviewed-on: https://go-review.googlesource.com/c/go/+/667755 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-21crypto/internal/fips140/nistec: remove dead s390x p256OrdMulFilippo Valsorda
The p256_ordinv.go file is build tagged to only amd64 and arm64, and there is no p256OrdSqr. Also, none of it will matter after CL 669895. Change-Id: I6a6a465653c18673e3a2c7f41d2e4ac54915b365 Reviewed-on: https://go-review.googlesource.com/c/go/+/675195 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-05-21crypto/tls: update BoGo SessionID test skip reasonsDaniel McCarney
Updates the skip reason for the following BoGo tests: * TLS-ECH-Client-TLS12SessionID * SupportTicketsWithSessionID * ResumeTLS12SessionID-TLS13 The crypto/tls package does not support session ID based resumption at this time, and so any tests that rely on this support need to be skipped. Updates #72006 Updates #25228 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/673737 TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-21crypto/tls: enable BoGo DisabledCurve-HelloRetryRequest-TLS13Daniel McCarney
The crypto/tls package produces the expected error for this test case, and so it can be enabled. Looking at the history of the relevant code it appears the TLS 1.3 implementation has always had the correct behaviour for HRR changing to an unsupported group after the initial hello. I think this test was skipped initially because at the time of initial BoGo config commit we hadn't implemented the -curves argument for the test shim yet, and this test relies on it. We later added support for that flag alongside X25519Kyber768Draft00 KX and I think we missed the chance to enable the test then. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cf Reviewed-on: https://go-review.googlesource.com/c/go/+/673756 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto/tls: match compression method alert across versionsDaniel McCarney
When a pre-TLS 1.3 server processes a client hello message that indicates compression methods that don't include the null compression method, send an illegal parameter alert. Previously we did this for TLS 1.3 server handshakes only, and the legacy TLS versions used alertHandshakeFailure for this circumstance. By switching this to alertIllegalParameter we use a consistent alert across all TLS versions, and can also enable the NoNullCompression-TLS12 BoGo test we were skipping. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5ce Reviewed-on: https://go-review.googlesource.com/c/go/+/673736 TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com>
2025-05-21crypto/tls: delete dead code curveIDForCurveDaniel McCarney
This unexported function has no call-sites. Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cd Reviewed-on: https://go-review.googlesource.com/c/go/+/673755 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto/tls: verify server chooses advertised curveDaniel McCarney
When a crypto/tls client using TLS < 1.3 sends supported elliptic_curves in a client hello message the server must limit itself to choosing one of the supported options from our message. If we process a server key exchange message that chooses an unadvertised curve, abort the handshake w/ an error. Previously we would not note that the server chose a curve we didn't include in the client hello message, and would proceed with the handshake as long as the chosen curve was one that we've implemented. However, RFC 8422 5.1 makes it clear this is a server acting out-of-spec, as it says: If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itself to the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite. Changing our behaviour to enforce this also allows enabling the UnsupportedCurve BoGo test. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cc Reviewed-on: https://go-review.googlesource.com/c/go/+/673735 TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-21internal/godebug,crypto/fips140: make fips140 setting immutableFilippo Valsorda
Updates #70123 Co-authored-by: qmuntal <quimmuntal@gmail.com> Change-Id: I6a6a4656fd23ecd82428cccbd7c48692287fc75a Reviewed-on: https://go-review.googlesource.com/c/go/+/657116 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
2025-05-21crypto/internal/fips140: use hash.HashFilippo Valsorda
Since package hash is just the interface definition, not an implementation, we can make a good argument that it doesn't impact the security of the module and can be imported from outside. For #69521 Change-Id: I6a6a4656b9c3cac8bb9ab8e8df11fa3238dc5d1d Reviewed-on: https://go-review.googlesource.com/c/go/+/674917 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-05-21crypto/tls: have servers prefer TLS 1.3 when supportedDaniel McCarney
Previously the common Config.mutualVersion() code prioritized the selected version based on the provided peerVersions being sent in peer preference order. Instead we would prefer to see TLS 1.3 used whenever it is supported, even if the peer would prefer an older protocol version. This commit updates mutualVersions() to implement this policy change. Our new behaviour matches the behaviour of other TLS stacks, notably BoringSSL, and so also allows enabling the IgnoreClientVersionOrder BoGo test that we otherwise must skip. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cb Reviewed-on: https://go-review.googlesource.com/c/go/+/673236 Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-21crypto/tls: add GetEncryptedClientHelloKeysRoland Shoemaker
This allows servers to rotate their ECH keys without needing to restart the server. Fixes #71920 Change-Id: I55591ab3303d5fde639038541c50edcf1fafc9aa Reviewed-on: https://go-review.googlesource.com/c/go/+/670655 TryBot-Bypass: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21crypto/sha1: use cryptotest.TestAllImplementations and impl.RegisterFilippo Valsorda
Not running TryBots on s390x because the new LUCI builder is broken. Change-Id: I6a6a4656a8d52fa5ace9effa67a88fbfd7d19b04 Reviewed-on: https://go-review.googlesource.com/c/go/+/674915 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-05-21crypto: drop pre-AVX2 SHA assembly implementationsRoland Shoemaker
Drop the entire pre-AVX2 assembly implementation of SHA-1, SHA-256, and SHA-512. This also technically impacts the SHA-1 AVX2 implementation, since it previously called the pre-AVX2 implementation for the last block if the number of blocks wasn't a multiple of 2. Instead of keeping the entire implementation just for that case, we just call the generic implementation for the last block. This will be a little slower, but still seems like a win. Updates #69587 Change-Id: Id5234c42910d8c6ec6b8df700a721c0953dff02b Reviewed-on: https://go-review.googlesource.com/c/go/+/657716 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2025-05-21crypto/internal/fips140/sha3: remove usages of WORD for s390xRoland Shoemaker
We support KIMD and KLMD now, paves the way for banning usage of BYTE and WORD instructions in crypto assembly. Change-Id: I0f93744663f23866b2269591db70389e0c77fa4a Reviewed-on: https://go-review.googlesource.com/c/go/+/671095 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-05-21crypto/x509: disallow negative path lengthMateusz Poliwczak
pathLenConstraint is restricted to unsigned integers. Also the -1 value of cert.MaxPathLength has a special meaning, so we shouldn't allow unmarshaling -1. BasicConstraints ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } Change-Id: I485a6aa7223127becc86c423e1ef9ed2fbd48209 GitHub-Last-Rev: 75a11b47b963ac383d1ad67dfc001648632a05f0 GitHub-Pull-Request: golang/go#60706 Reviewed-on: https://go-review.googlesource.com/c/go/+/502076 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com>
2025-05-21crypto/tls: replace custom intern cache with weak cacheRoland Shoemaker
Uses the new weak package to replace the existing custom intern cache with a map of weak.Pointers instead. This simplifies the cache, and means we don't need to store a slice of handles on the Conn anymore. Change-Id: I5c2bf6ef35fac4255e140e184f4e48574b34174c Reviewed-on: https://go-review.googlesource.com/c/go/+/644176 TryBot-Bypass: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org>
2025-05-21crypto/sha1: add sha-ni AMD64 implementationRoland Shoemaker
Based on the Intel docs. Provides a ~44% speed-up compared to the AVX implementation and a ~57% speed-up compared to the generic AMD64 assembly implementation. │ /usr/local/google/home/bracewell/sha1-avx.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │ │ sec/op │ sec/op vs base │ Hash8Bytes/New-24 157.60n ± 0% 92.51n ± 0% -41.30% (p=0.000 n=20) Hash8Bytes/Sum-24 147.00n ± 0% 85.06n ± 0% -42.14% (p=0.000 n=20) Hash320Bytes/New-24 625.3n ± 0% 276.7n ± 0% -55.75% (p=0.000 n=20) Hash320Bytes/Sum-24 626.2n ± 0% 272.4n ± 0% -56.51% (p=0.000 n=20) Hash1K/New-24 1206.5n ± 0% 692.2n ± 0% -42.63% (p=0.000 n=20) Hash1K/Sum-24 1210.0n ± 0% 688.2n ± 0% -43.13% (p=0.000 n=20) Hash8K/New-24 7.744µ ± 0% 4.920µ ± 0% -36.46% (p=0.000 n=20) Hash8K/Sum-24 7.737µ ± 0% 4.913µ ± 0% -36.50% (p=0.000 n=20) geomean 971.5n 536.1n -44.81% │ /usr/local/google/home/bracewell/sha1-avx.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │ │ B/s │ B/s vs base │ Hash8Bytes/New-24 48.41Mi ± 0% 82.47Mi ± 0% +70.37% (p=0.000 n=20) Hash8Bytes/Sum-24 51.90Mi ± 0% 89.70Mi ± 0% +72.82% (p=0.000 n=20) Hash320Bytes/New-24 488.0Mi ± 0% 1103.0Mi ± 0% +126.01% (p=0.000 n=20) Hash320Bytes/Sum-24 487.4Mi ± 0% 1120.5Mi ± 0% +129.91% (p=0.000 n=20) Hash1K/New-24 809.6Mi ± 0% 1410.8Mi ± 0% +74.26% (p=0.000 n=20) Hash1K/Sum-24 806.9Mi ± 0% 1419.1Mi ± 0% +75.86% (p=0.000 n=20) Hash8K/New-24 1008.9Mi ± 0% 1588.0Mi ± 0% +57.40% (p=0.000 n=20) Hash8K/Sum-24 1009.8Mi ± 0% 1590.1Mi ± 0% +57.47% (p=0.000 n=20) geomean 375.8Mi 680.9Mi +81.20% │ /usr/local/google/home/bracewell/sha1-amd64.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │ │ sec/op │ sec/op vs base │ Hash8Bytes/New-24 153.90n ± 0% 92.51n ± 0% -39.89% (p=0.000 n=20) Hash8Bytes/Sum-24 145.90n ± 0% 85.06n ± 0% -41.70% (p=0.000 n=20) Hash320Bytes/New-24 666.8n ± 0% 276.7n ± 0% -58.50% (p=0.000 n=20) Hash320Bytes/Sum-24 660.3n ± 0% 272.4n ± 0% -58.75% (p=0.000 n=20) Hash1K/New-24 1810.5n ± 0% 692.2n ± 0% -61.77% (p=0.000 n=20) Hash1K/Sum-24 1806.0n ± 0% 688.2n ± 0% -61.90% (p=0.000 n=20) Hash8K/New-24 13.509µ ± 0% 4.920µ ± 0% -63.58% (p=0.000 n=20) Hash8K/Sum-24 13.515µ ± 0% 4.913µ ± 0% -63.65% (p=0.000 n=20) geomean 1.248µ 536.1n -57.05% │ /usr/local/google/home/bracewell/sha1-amd64.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │ │ B/s │ B/s vs base │ Hash8Bytes/New-24 49.57Mi ± 0% 82.47Mi ± 0% +66.37% (p=0.000 n=20) Hash8Bytes/Sum-24 52.29Mi ± 0% 89.70Mi ± 0% +71.52% (p=0.000 n=20) Hash320Bytes/New-24 457.7Mi ± 0% 1103.0Mi ± 0% +140.97% (p=0.000 n=20) Hash320Bytes/Sum-24 462.2Mi ± 0% 1120.5Mi ± 0% +142.45% (p=0.000 n=20) Hash1K/New-24 539.4Mi ± 0% 1410.8Mi ± 0% +161.57% (p=0.000 n=20) Hash1K/Sum-24 540.7Mi ± 0% 1419.1Mi ± 0% +162.44% (p=0.000 n=20) Hash8K/New-24 578.4Mi ± 0% 1588.0Mi ± 0% +174.57% (p=0.000 n=20) Hash8K/Sum-24 578.1Mi ± 0% 1590.1Mi ± 0% +175.07% (p=0.000 n=20) geomean 292.4Mi 680.9Mi +132.86% Change-Id: Ife90386ba410a80c2e6222c1fe4df2368c4e12b2 Reviewed-on: https://go-review.googlesource.com/c/go/+/642157 Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Neal Patel <nealpatel@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-20crypto/subtle: optimize function xorBytes using SIMD on loong64Xiaolin Zhao
On the Loongson-3A6000-HV and Loongson-3A5000, there has been a significant improvement in all performance metrics except for '8Bytes', which has experienced a decline, as follows. goos: linux goarch: loong64 pkg: crypto/subtle cpu: Loongson-3A6000-HV @ 2500.00MHz | bench.old | bench.new | | sec/op | sec/op vs base | XORBytes/8Bytes 7.282n ± 0% 8.805n ± 0% +20.91% (p=0.000 n=10) XORBytes/128Bytes 14.43n ± 0% 10.01n ± 0% -30.63% (p=0.000 n=10) XORBytes/2048Bytes 110.60n ± 0% 46.57n ± 0% -57.89% (p=0.000 n=10) XORBytes/8192Bytes 418.7n ± 0% 161.8n ± 0% -61.36% (p=0.000 n=10) XORBytes/32768Bytes 3.220µ ± 0% 1.673µ ± 0% -48.04% (p=0.000 n=10) XORBytesAlignment/8Bytes0Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes1Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes2Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes3Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes4Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes5Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes6Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/8Bytes7Offset 7.621n ± 0% 9.305n ± 0% +22.10% (p=0.000 n=10) XORBytesAlignment/128Bytes0Offset 14.430n ± 0% 9.973n ± 0% -30.88% (p=0.000 n=10) XORBytesAlignment/128Bytes1Offset 20.83n ± 0% 11.03n ± 0% -47.05% (p=0.000 n=10) XORBytesAlignment/128Bytes2Offset 20.83n ± 0% 11.03n ± 0% -47.07% (p=0.000 n=10) XORBytesAlignment/128Bytes3Offset 20.83n ± 0% 11.03n ± 0% -47.07% (p=0.000 n=10) XORBytesAlignment/128Bytes4Offset 20.83n ± 0% 11.03n ± 0% -47.05% (p=0.000 n=10) XORBytesAlignment/128Bytes5Offset 20.83n ± 0% 11.03n ± 0% -47.05% (p=0.000 n=10) XORBytesAlignment/128Bytes6Offset 20.83n ± 0% 11.03n ± 0% -47.05% (p=0.000 n=10) XORBytesAlignment/128Bytes7Offset 20.83n ± 0% 11.03n ± 0% -47.05% (p=0.000 n=10) XORBytesAlignment/2048Bytes0Offset 110.60n ± 0% 46.82n ± 0% -57.67% (p=0.000 n=10) XORBytesAlignment/2048Bytes1Offset 234.4n ± 0% 109.3n ± 0% -53.37% (p=0.000 n=10) XORBytesAlignment/2048Bytes2Offset 234.4n ± 0% 109.3n ± 0% -53.37% (p=0.000 n=10) XORBytesAlignment/2048Bytes3Offset 234.4n ± 0% 109.3n ± 0% -53.37% (p=0.000 n=10) XORBytesAlignment/2048Bytes4Offset 234.5n ± 0% 109.3n ± 0% -53.39% (p=0.000 n=10) XORBytesAlignment/2048Bytes5Offset 234.4n ± 0% 109.3n ± 0% -53.37% (p=0.000 n=10) XORBytesAlignment/2048Bytes6Offset 234.4n ± 0% 109.3n ± 0% -53.37% (p=0.000 n=10) XORBytesAlignment/2048Bytes7Offset 234.5n ± 0% 109.3n ± 0% -53.39% (p=0.000 n=10) geomean 39.42n 26.00n -34.05% goos: linux goarch: loong64 pkg: crypto/subtle cpu: Loongson-3A5000 @ 2500.00MHz | bench.old | bench.new | | sec/op | sec/op vs base | XORBytes/8Bytes 11.21n ± 0% 12.41n ± 1% +10.70% (p=0.000 n=10) XORBytes/128Bytes 18.22n ± 0% 13.61n ± 0% -25.30% (p=0.000 n=10) XORBytes/2048Bytes 162.20n ± 0% 48.46n ± 0% -70.13% (p=0.000 n=10) XORBytes/8192Bytes 629.8n ± 0% 163.8n ± 0% -73.99% (p=0.000 n=10) XORBytes/32768Bytes 4731.0n ± 1% 632.8n ± 0% -86.63% (p=0.000 n=10) XORBytesAlignment/8Bytes0Offset 11.61n ± 1% 12.42n ± 0% +6.98% (p=0.000 n=10) XORBytesAlignment/8Bytes1Offset 11.61n ± 0% 12.41n ± 0% +6.89% (p=0.000 n=10) XORBytesAlignment/8Bytes2Offset 11.61n ± 0% 12.42n ± 0% +6.98% (p=0.000 n=10) XORBytesAlignment/8Bytes3Offset 11.61n ± 0% 12.41n ± 0% +6.89% (p=0.000 n=10) XORBytesAlignment/8Bytes4Offset 11.61n ± 0% 12.42n ± 0% +6.98% (p=0.000 n=10) XORBytesAlignment/8Bytes5Offset 11.61n ± 0% 12.41n ± 0% +6.89% (p=0.000 n=10) XORBytesAlignment/8Bytes6Offset 11.61n ± 0% 12.41n ± 1% +6.89% (p=0.000 n=10) XORBytesAlignment/8Bytes7Offset 11.61n ± 0% 12.42n ± 0% +6.98% (p=0.000 n=10) XORBytesAlignment/128Bytes0Offset 17.82n ± 0% 13.62n ± 0% -23.57% (p=0.000 n=10) XORBytesAlignment/128Bytes1Offset 26.62n ± 0% 18.43n ± 0% -30.78% (p=0.000 n=10) XORBytesAlignment/128Bytes2Offset 26.64n ± 0% 18.43n ± 0% -30.85% (p=0.000 n=10) XORBytesAlignment/128Bytes3Offset 26.65n ± 0% 18.42n ± 0% -30.90% (p=0.000 n=10) XORBytesAlignment/128Bytes4Offset 26.65n ± 0% 18.42n ± 0% -30.88% (p=0.000 n=10) XORBytesAlignment/128Bytes5Offset 26.62n ± 0% 18.42n ± 0% -30.82% (p=0.000 n=10) XORBytesAlignment/128Bytes6Offset 26.63n ± 0% 18.42n ± 0% -30.84% (p=0.000 n=10) XORBytesAlignment/128Bytes7Offset 26.64n ± 0% 18.42n ± 0% -30.86% (p=0.000 n=10) XORBytesAlignment/2048Bytes0Offset 161.80n ± 0% 48.25n ± 0% -70.18% (p=0.000 n=10) XORBytesAlignment/2048Bytes1Offset 354.6n ± 0% 189.2n ± 0% -46.64% (p=0.000 n=10) XORBytesAlignment/2048Bytes2Offset 354.6n ± 0% 189.2n ± 0% -46.64% (p=0.000 n=10) XORBytesAlignment/2048Bytes3Offset 354.7n ± 0% 189.2n ± 0% -46.66% (p=0.000 n=10) XORBytesAlignment/2048Bytes4Offset 354.7n ± 0% 189.2n ± 1% -46.66% (p=0.000 n=10) XORBytesAlignment/2048Bytes5Offset 354.7n ± 0% 189.2n ± 0% -46.66% (p=0.000 n=10) XORBytesAlignment/2048Bytes6Offset 354.7n ± 0% 189.2n ± 0% -46.66% (p=0.000 n=10) XORBytesAlignment/2048Bytes7Offset 354.8n ± 0% 189.2n ± 0% -46.67% (p=0.000 n=10) geomean 56.46n 36.46n -35.42% Change-Id: I66e150b132517e9ff4827abf796812ffe608c052 Reviewed-on: https://go-review.googlesource.com/c/go/+/673355 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-20crypto/ecdsa,crypto/ed25519: cache FIPS private keysFilippo Valsorda
All private keys need to go through a slow PCT in FIPS-140 mode. ECDH and RSA keys have places to hide a precomputed value without causing races, but Ed25519 and ECDSA keys might be constructed by the application and then used with concurrent Sign calls. For these, implement an equivalent to crypto/internal/boring/bcache using weak.Pointer and runtime.AddCleanup. fips140: latest goos: linux goarch: amd64 pkg: crypto/ed25519 cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics │ 1a93e4a2cf │ 78a819ea78 │ │ sec/op │ sec/op vs base │ Signing-16 72.72µ ± 0% 16.93µ ± 1% -76.72% (p=0.002 n=6) fips140: off goos: linux goarch: amd64 pkg: crypto/ed25519 cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics │ 310bad31e5 │ 310bad31e5-dirty │ │ sec/op │ sec/op vs base │ Signing-16 17.18µ ± 1% 16.95µ ± 1% -1.36% (p=0.002 n=6) fips140: latest goos: linux goarch: amd64 pkg: crypto/ecdsa cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics │ 1a93e4a2cf │ 78a819ea78 │ │ sec/op │ sec/op vs base │ Sign/P256-16 90.97µ ± 0% 21.04µ ± 0% -76.87% (p=0.002 n=6) Sign/P384-16 701.6µ ± 1% 142.0µ ± 0% -79.75% (p=0.002 n=6) Sign/P521-16 2943.5µ ± 1% 491.9µ ± 0% -83.29% (p=0.002 n=6) fips140: off goos: linux goarch: amd64 pkg: crypto/ecdsa cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics │ 1a93e4a2cf │ 78a819ea78 │ │ sec/op │ sec/op vs base │ Sign/P256-16 21.27µ ± 0% 21.13µ ± 0% -0.65% (p=0.002 n=6) Sign/P384-16 143.3µ ± 0% 142.4µ ± 0% -0.63% (p=0.009 n=6) Sign/P521-16 525.3µ ± 0% 462.1µ ± 0% -12.04% (p=0.002 n=6) This unavoidably introduces allocations in the very first use of Ed25519 private keys, but usually that's not in the hot path. Change-Id: I6a6a465640a5dff64edd73ee5dda5f2ad1b476b9 Reviewed-on: https://go-review.googlesource.com/c/go/+/654096 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-15crypto/tls: fix bogo IgnoreClientVersionOrder skip reasonDaniel McCarney
The BoGo IgnoreClientVersionOrder test checks that a client that sends a supported_versions extension with the list [TLS 1.2, TLS 1.3] ends up negotiating TLS 1.3. However, the crypto/tls module treats this list as being in client preference order, and so negotiates TLS 1.2, failing the test. Our behaviour appears to be the correct handling based on RFC 8446 §4.2.1 where it says: The extension contains a list of supported versions in preference order, with the most preferred version first. This commit updates the reason we skip this test to cite the RFC instead of saying it's something to be fixed. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5ca Reviewed-on: https://go-review.googlesource.com/c/go/+/671415 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
2025-05-14crypto/internal/fips140/subtle: add assembly implementation of xorBytes for armJulian Zhu
goos: linux goarch: arm pkg: crypto/subtle │ o │ n │ │ sec/op │ sec/op vs base │ ConstantTimeByteEq-4 5.353n ± 88% 4.012n ± 67% ~ (p=0.381 n=8) ConstantTimeEq-4 4.151n ± 1% 4.078n ± 0% -1.76% (p=0.000 n=8) ConstantTimeLessOrEq-4 4.010n ± 15% 4.154n ± 3% ~ (p=0.584 n=8) XORBytes/8Bytes-4 85.69n ± 13% 44.02n ± 1% -48.64% (p=0.000 n=8) XORBytes/128Bytes-4 164.85n ± 9% 84.62n ± 5% -48.67% (p=0.000 n=8) XORBytes/2048Bytes-4 1374.0n ± 1% 741.2n ± 15% -46.05% (p=0.000 n=8) XORBytes/8192Bytes-4 4.357µ ± 0% 2.801µ ± 0% -35.71% (p=0.000 n=8) XORBytes/32768Bytes-4 16.67µ ± 0% 11.96µ ± 0% -28.26% (p=0.000 n=8) XORBytesAlignment/8Bytes0Offset-4 83.28n ± 0% 42.77n ± 1% -48.65% (p=0.000 n=8) XORBytesAlignment/8Bytes1Offset-4 61.52n ± 1% 50.30n ± 16% -18.24% (p=0.000 n=8) XORBytesAlignment/8Bytes2Offset-4 61.75n ± 1% 42.72n ± 1% -30.82% (p=0.000 n=8) XORBytesAlignment/8Bytes3Offset-4 61.53n ± 1% 42.70n ± 1% -30.60% (p=0.000 n=8) XORBytesAlignment/8Bytes4Offset-4 83.28n ± 0% 42.71n ± 1% -48.72% (p=0.000 n=8) XORBytesAlignment/8Bytes5Offset-4 61.53n ± 0% 42.73n ± 1% -30.55% (p=0.000 n=8) XORBytesAlignment/8Bytes6Offset-4 61.58n ± 0% 42.69n ± 1% -30.68% (p=0.000 n=8) XORBytesAlignment/8Bytes7Offset-4 61.63n ± 1% 42.70n ± 1% -30.72% (p=0.000 n=8) XORBytesAlignment/128Bytes0Offset-4 154.15n ± 4% 83.48n ± 0% -45.84% (p=0.000 n=8) XORBytesAlignment/128Bytes1Offset-4 265.25n ± 0% 91.70n ± 8% -65.43% (p=0.000 n=8) XORBytesAlignment/128Bytes2Offset-4 265.20n ± 0% 98.09n ± 13% -63.01% (p=0.000 n=8) XORBytesAlignment/128Bytes3Offset-4 265.20n ± 0% 85.48n ± 0% -67.77% (p=0.000 n=8) XORBytesAlignment/128Bytes4Offset-4 150.05n ± 0% 83.52n ± 15% -44.34% (p=0.000 n=8) XORBytesAlignment/128Bytes5Offset-4 265.20n ± 0% 85.48n ± 15% -67.77% (p=0.000 n=8) XORBytesAlignment/128Bytes6Offset-4 265.20n ± 0% 96.16n ± 11% -63.74% (p=0.000 n=8) XORBytesAlignment/128Bytes7Offset-4 265.20n ± 0% 85.49n ± 0% -67.76% (p=0.000 n=8) XORBytesAlignment/2048Bytes0Offset-4 1114.0n ± 0% 739.5n ± 0% -33.62% (p=0.000 n=8) XORBytesAlignment/2048Bytes1Offset-4 3285.0n ± 15% 783.5n ± 0% -76.15% (p=0.000 n=8) XORBytesAlignment/2048Bytes2Offset-4 3288.0n ± 15% 783.6n ± 25% -76.17% (p=0.000 n=8) XORBytesAlignment/2048Bytes3Offset-4 3286.0n ± 0% 783.5n ± 0% -76.15% (p=0.000 n=8) XORBytesAlignment/2048Bytes4Offset-4 1116.0n ± 115% 742.9n ± 0% -33.43% (p=0.000 n=8) XORBytesAlignment/2048Bytes5Offset-4 3285.0n ± 0% 785.0n ± 0% -76.10% (p=0.000 n=8) XORBytesAlignment/2048Bytes6Offset-4 3284.0n ± 0% 784.8n ± 0% -76.10% (p=0.000 n=8) XORBytesAlignment/2048Bytes7Offset-4 3283.0n ± 0% 784.9n ± 0% -76.09% (p=0.000 n=8) geomean 269.5n 129.5n -51.93% │ o │ n │ │ B/s │ B/s vs base │ XORBytes/8Bytes-4 89.08Mi ± 11% 173.34Mi ± 1% +94.58% (p=0.000 n=8) XORBytes/128Bytes-4 741.9Mi ± 10% 1442.6Mi ± 13% +94.45% (p=0.000 n=8) XORBytes/2048Bytes-4 1.388Gi ± 0% 2.573Gi ± 13% +85.40% (p=0.000 n=8) XORBytes/8192Bytes-4 1.751Gi ± 1% 2.724Gi ± 0% +55.57% (p=0.000 n=8) XORBytes/32768Bytes-4 1.830Gi ± 0% 2.551Gi ± 0% +39.38% (p=0.000 n=8) XORBytesAlignment/8Bytes0Offset-4 91.61Mi ± 0% 178.40Mi ± 1% +94.75% (p=0.000 n=8) XORBytesAlignment/8Bytes1Offset-4 124.0Mi ± 1% 152.2Mi ± 18% +22.73% (p=0.000 n=8) XORBytesAlignment/8Bytes2Offset-4 123.6Mi ± 1% 178.6Mi ± 14% +44.54% (p=0.000 n=8) XORBytesAlignment/8Bytes3Offset-4 124.0Mi ± 1% 178.6Mi ± 1% +44.10% (p=0.000 n=8) XORBytesAlignment/8Bytes4Offset-4 91.61Mi ± 0% 178.65Mi ± 1% +95.01% (p=0.000 n=8) XORBytesAlignment/8Bytes5Offset-4 124.0Mi ± 1% 178.5Mi ± 1% +43.98% (p=0.000 n=8) XORBytesAlignment/8Bytes6Offset-4 123.9Mi ± 1% 178.7Mi ± 1% +44.23% (p=0.000 n=8) XORBytesAlignment/8Bytes7Offset-4 123.8Mi ± 6% 178.7Mi ± 1% +44.33% (p=0.000 n=8) XORBytesAlignment/128Bytes0Offset-4 792.5Mi ± 4% 1462.3Mi ± 13% +84.51% (p=0.000 n=8) XORBytesAlignment/128Bytes1Offset-4 460.2Mi ± 0% 1337.2Mi ± 8% +190.56% (p=0.000 n=8) XORBytesAlignment/128Bytes2Offset-4 460.2Mi ± 0% 1244.6Mi ± 15% +170.42% (p=0.000 n=8) XORBytesAlignment/128Bytes3Offset-4 460.3Mi ± 0% 1428.1Mi ± 0% +210.27% (p=0.000 n=8) XORBytesAlignment/128Bytes4Offset-4 813.5Mi ± 0% 1461.6Mi ± 13% +79.67% (p=0.000 n=8) XORBytesAlignment/128Bytes5Offset-4 460.3Mi ± 0% 1428.0Mi ± 13% +210.25% (p=0.000 n=8) XORBytesAlignment/128Bytes6Offset-4 460.3Mi ± 0% 1285.1Mi ± 11% +179.16% (p=0.000 n=8) XORBytesAlignment/128Bytes7Offset-4 460.2Mi ± 0% 1427.9Mi ± 18% +210.25% (p=0.000 n=8) XORBytesAlignment/2048Bytes0Offset-4 1.711Gi ± 0% 2.579Gi ± 0% +50.71% (p=0.000 n=8) XORBytesAlignment/2048Bytes1Offset-4 594.5Mi ± 13% 2493.0Mi ± 20% +319.35% (p=0.000 n=8) XORBytesAlignment/2048Bytes2Offset-4 594.0Mi ± 13% 2492.7Mi ± 20% +319.63% (p=0.000 n=8) XORBytesAlignment/2048Bytes3Offset-4 594.4Mi ± 53% 2492.8Mi ± 0% +319.35% (p=0.000 n=8) XORBytesAlignment/2048Bytes4Offset-4 1.710Gi ± 53% 2.567Gi ± 0% +50.17% (p=0.000 n=8) XORBytesAlignment/2048Bytes5Offset-4 594.5Mi ± 0% 2487.9Mi ± 0% +318.47% (p=0.000 n=8) XORBytesAlignment/2048Bytes6Offset-4 594.8Mi ± 0% 2488.6Mi ± 0% +318.41% (p=0.000 n=8) XORBytesAlignment/2048Bytes7Offset-4 594.9Mi ± 0% 2488.3Mi ± 0% +318.28% (p=0.000 n=8) geomean 414.2Mi 921.5Mi +122.46% Change-Id: I0ac50135de2e69fcf802be31e5175d666c93ad4c Reviewed-on: https://go-review.googlesource.com/c/go/+/667817 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2025-05-13crypto/x509: decouple key usage and policy validationRoland Shoemaker
Disabling key usage validation (by passing ExtKeyUsageAny) unintentionally disabled policy validation. This change decouples these two checks, preventing the user from unintentionally disabling policy validation. Thanks to Krzysztof Skrzętnicki (@Tener) of Teleport for reporting this issue. Fixes #73612 Fixes CVE-2025-22874 Change-Id: Iec8f080a8879a3dd44cb3da30352fa3e7f539d40 Reviewed-on: https://go-review.googlesource.com/c/go/+/670375 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Stapleton Cordasco <graffatcolmingov@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-13crypto: limit md5 or sha256 blocks processed at once in assemblyRadu Berinde
This change limits the amount of data that can be hashed at once - the assembly routines are not preemptible and can result in large latency outliers when part of a larger system. Benchmarks for sha256 (on an arm64 M1): name old speed new speed delta Hash8Bytes/New-10 178MB/s ± 0% 178MB/s ± 0% +0.16% (p=0.002 n=9+8) Hash8Bytes/Sum224-10 154MB/s ± 0% 154MB/s ± 0% ~ (p=0.287 n=9+10) Hash8Bytes/Sum256-10 156MB/s ± 0% 157MB/s ± 0% +0.13% (p=0.004 n=9+8) Hash1K/New-10 2.28GB/s ± 0% 2.28GB/s ± 0% ~ (p=0.968 n=10+9) Hash1K/Sum224-10 2.20GB/s ± 0% 2.21GB/s ± 0% +0.30% (p=0.001 n=9+9) Hash1K/Sum256-10 2.21GB/s ± 0% 2.21GB/s ± 0% +0.26% (p=0.000 n=9+8) Hash8K/New-10 2.37GB/s ± 2% 2.40GB/s ± 0% ~ (p=0.289 n=10+10) Hash8K/Sum224-10 2.39GB/s ± 0% 2.39GB/s ± 0% ~ (p=0.983 n=8+9) Hash8K/Sum256-10 2.39GB/s ± 0% 2.39GB/s ± 0% ~ (p=0.905 n=9+10) Hash256K/New-10 2.42GB/s ± 0% 2.42GB/s ± 0% ~ (p=0.250 n=9+10) Hash256K/Sum224-10 2.42GB/s ± 0% 2.42GB/s ± 0% ~ (p=0.093 n=8+9) Hash256K/Sum256-10 2.42GB/s ± 0% 2.42GB/s ± 0% ~ (p=0.211 n=10+9) Hash1M/New-10 2.42GB/s ± 0% 2.42GB/s ± 0% ~ (p=0.963 n=8+9) Hash1M/Sum224-10 2.42GB/s ± 0% 2.42GB/s ± 0% ~ (p=0.173 n=10+8) Hash1M/Sum256-10 2.42GB/s ± 0% 2.42GB/s ± 0% ~ (p=0.743 n=9+8) Note that `Hash8K` shows that a 8K block size is sufficient to achieve peak bandwidth, so the 64KB maxAsmSize should be plenty. Benchmarks for md5: name old speed new speed delta Hash1M-10 669MB/s ± 0% 669MB/s ± 0% ~ (p=0.965 n=8+10) Hash8M-10 667MB/s ± 0% 666MB/s ± 0% ~ (p=0.356 n=10+9) Fixes #64417 Change-Id: If7f5e7587b33c65148f49859c9d46ae6f6948db4 GitHub-Last-Rev: 2f83f4255412b533469e953db6c1ef16fa3eb7c2 GitHub-Pull-Request: golang/go#73638 Reviewed-on: https://go-review.googlesource.com/c/go/+/671098 Reviewed-by: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Ian Stapleton Cordasco <graffatcolmingov@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-05-12crypto/internal/fips140/subtle: add assembly implementation of xorBytes for ↵Julian Zhu
mipsx goos: linux goarch: mipsle pkg: crypto/subtle │ osubtle │ nsubtle │ │ sec/op │ sec/op vs base │ ConstantTimeByteEq-4 2.785n ± 0% 2.785n ± 0% ~ (p=0.876 n=8) ConstantTimeEq-4 3.342n ± 0% 3.341n ± 0% ~ (p=0.258 n=8) ConstantTimeLessOrEq-4 3.341n ± 0% 3.340n ± 0% ~ (p=0.370 n=8) XORBytes/8Bytes-4 117.80n ± 0% 27.02n ± 2% -77.07% (p=0.000 n=8) XORBytes/128Bytes-4 176.60n ± 0% 58.42n ± 4% -66.92% (p=0.000 n=8) XORBytes/2048Bytes-4 996.5n ± 0% 462.4n ± 0% -53.60% (p=0.000 n=8) XORBytes/8192Bytes-4 3.568µ ± 0% 1.780µ ± 2% -50.13% (p=0.000 n=8) XORBytes/32768Bytes-4 19.34µ ± 6% 10.52µ ± 5% -45.60% (p=0.000 n=8) XORBytesAlignment/8Bytes0Offset-4 127.50n ± 0% 28.31n ± 1% -77.80% (p=0.000 n=8) XORBytesAlignment/8Bytes1Offset-4 105.65n ± 1% 28.20n ± 1% -73.30% (p=0.000 n=8) XORBytesAlignment/8Bytes2Offset-4 105.55n ± 1% 28.34n ± 1% -73.15% (p=0.000 n=8) XORBytesAlignment/8Bytes3Offset-4 105.65n ± 0% 28.45n ± 1% -73.07% (p=0.000 n=8) XORBytesAlignment/8Bytes4Offset-4 127.60n ± 0% 28.19n ± 1% -77.91% (p=0.000 n=8) XORBytesAlignment/8Bytes5Offset-4 105.45n ± 0% 28.38n ± 1% -73.09% (p=0.000 n=8) XORBytesAlignment/8Bytes6Offset-4 105.55n ± 0% 28.27n ± 1% -73.22% (p=0.000 n=8) XORBytesAlignment/8Bytes7Offset-4 105.60n ± 0% 28.24n ± 1% -73.26% (p=0.000 n=8) XORBytesAlignment/128Bytes0Offset-4 178.25n ± 0% 59.57n ± 0% -66.58% (p=0.000 n=8) XORBytesAlignment/128Bytes1Offset-4 313.25n ± 0% 75.32n ± 0% -75.96% (p=0.000 n=8) XORBytesAlignment/128Bytes2Offset-4 313.75n ± 0% 75.34n ± 0% -75.99% (p=0.000 n=8) XORBytesAlignment/128Bytes3Offset-4 314.25n ± 0% 75.31n ± 0% -76.04% (p=0.000 n=8) XORBytesAlignment/128Bytes4Offset-4 178.25n ± 0% 59.57n ± 0% -66.58% (p=0.000 n=8) XORBytesAlignment/128Bytes5Offset-4 314.20n ± 0% 75.80n ± 1% -75.88% (p=0.000 n=8) XORBytesAlignment/128Bytes6Offset-4 313.30n ± 0% 75.56n ± 0% -75.88% (p=0.000 n=8) XORBytesAlignment/128Bytes7Offset-4 313.95n ± 0% 75.45n ± 0% -75.97% (p=0.000 n=8) XORBytesAlignment/2048Bytes0Offset-4 1002.5n ± 0% 455.3n ± 0% -54.58% (p=0.000 n=8) XORBytesAlignment/2048Bytes1Offset-4 3649.5n ± 0% 731.6n ± 0% -79.95% (p=0.000 n=8) XORBytesAlignment/2048Bytes2Offset-4 3645.0n ± 0% 731.5n ± 0% -79.93% (p=0.000 n=8) XORBytesAlignment/2048Bytes3Offset-4 3656.0n ± 0% 731.6n ± 0% -79.99% (p=0.000 n=8) XORBytesAlignment/2048Bytes4Offset-4 1003.0n ± 0% 455.6n ± 0% -54.58% (p=0.000 n=8) XORBytesAlignment/2048Bytes5Offset-4 3651.5n ± 1% 736.6n ± 0% -79.83% (p=0.000 n=8) XORBytesAlignment/2048Bytes6Offset-4 3647.5n ± 0% 736.4n ± 0% -79.81% (p=0.000 n=8) XORBytesAlignment/2048Bytes7Offset-4 3657.0n ± 1% 736.6n ± 0% -79.86% (p=0.000 n=8) geomean 313.1n 96.95n -69.03% │ osubtle │ nsubtle │ │ B/s │ B/s vs base │ XORBytes/8Bytes-4 64.77Mi ± 0% 282.51Mi ± 2% +336.18% (p=0.000 n=8) XORBytes/128Bytes-4 691.3Mi ± 0% 2092.3Mi ± 4% +202.66% (p=0.000 n=8) XORBytes/2048Bytes-4 1.914Gi ± 0% 4.125Gi ± 0% +115.51% (p=0.000 n=8) XORBytes/8192Bytes-4 2.138Gi ± 0% 4.288Gi ± 2% +100.54% (p=0.000 n=8) XORBytes/32768Bytes-4 1.583Gi ± 6% 2.908Gi ± 5% +83.61% (p=0.000 n=8) XORBytesAlignment/8Bytes0Offset-4 59.83Mi ± 0% 269.47Mi ± 1% +350.37% (p=0.000 n=8) XORBytesAlignment/8Bytes1Offset-4 72.22Mi ± 0% 270.51Mi ± 1% +274.56% (p=0.000 n=8) XORBytesAlignment/8Bytes2Offset-4 72.28Mi ± 1% 269.19Mi ± 1% +272.41% (p=0.000 n=8) XORBytesAlignment/8Bytes3Offset-4 72.21Mi ± 0% 268.16Mi ± 1% +271.38% (p=0.000 n=8) XORBytesAlignment/8Bytes4Offset-4 59.79Mi ± 0% 270.67Mi ± 1% +352.74% (p=0.000 n=8) XORBytesAlignment/8Bytes5Offset-4 72.36Mi ± 0% 268.83Mi ± 1% +271.49% (p=0.000 n=8) XORBytesAlignment/8Bytes6Offset-4 72.29Mi ± 0% 269.95Mi ± 1% +273.44% (p=0.000 n=8) XORBytesAlignment/8Bytes7Offset-4 72.27Mi ± 0% 270.14Mi ± 1% +273.79% (p=0.000 n=8) XORBytesAlignment/128Bytes0Offset-4 684.7Mi ± 0% 2049.1Mi ± 0% +199.26% (p=0.000 n=8) XORBytesAlignment/128Bytes1Offset-4 389.7Mi ± 1% 1620.7Mi ± 0% +315.86% (p=0.000 n=8) XORBytesAlignment/128Bytes2Offset-4 389.1Mi ± 0% 1620.3Mi ± 0% +316.41% (p=0.000 n=8) XORBytesAlignment/128Bytes3Offset-4 388.4Mi ± 1% 1620.9Mi ± 0% +317.29% (p=0.000 n=8) XORBytesAlignment/128Bytes4Offset-4 684.8Mi ± 0% 2049.2Mi ± 0% +199.24% (p=0.000 n=8) XORBytesAlignment/128Bytes5Offset-4 388.5Mi ± 0% 1610.3Mi ± 1% +314.47% (p=0.000 n=8) XORBytesAlignment/128Bytes6Offset-4 389.6Mi ± 0% 1615.4Mi ± 0% +314.60% (p=0.000 n=8) XORBytesAlignment/128Bytes7Offset-4 388.9Mi ± 0% 1617.8Mi ± 1% +316.04% (p=0.000 n=8) XORBytesAlignment/2048Bytes0Offset-4 1.903Gi ± 3% 4.189Gi ± 3% +120.18% (p=0.000 n=8) XORBytesAlignment/2048Bytes1Offset-4 535.1Mi ± 0% 2669.7Mi ± 0% +398.88% (p=0.000 n=8) XORBytesAlignment/2048Bytes2Offset-4 535.8Mi ± 0% 2670.1Mi ± 0% +398.34% (p=0.000 n=8) XORBytesAlignment/2048Bytes3Offset-4 534.2Mi ± 0% 2669.6Mi ± 0% +399.71% (p=0.000 n=8) XORBytesAlignment/2048Bytes4Offset-4 1.902Gi ± 0% 4.187Gi ± 0% +120.12% (p=0.000 n=8) XORBytesAlignment/2048Bytes5Offset-4 534.9Mi ± 0% 2651.6Mi ± 0% +395.73% (p=0.000 n=8) XORBytesAlignment/2048Bytes6Offset-4 535.5Mi ± 0% 2652.3Mi ± 0% +395.34% (p=0.000 n=8) XORBytesAlignment/2048Bytes7Offset-4 534.1Mi ± 1% 2651.6Mi ± 0% +396.46% (p=0.000 n=8) geomean 338.6Mi 1.205Gi +264.51% Change-Id: I4d7e759968779cf8470826b8662b9f2018e663bc Reviewed-on: https://go-review.googlesource.com/c/go/+/666275 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@google.com>
2025-05-11crypto/sha1: replaced WORD with instruction REVB2WXiaolin Zhao
Change-Id: I37f3db37a318a72a9558c1a728be8099a41a8774 Reviewed-on: https://go-review.googlesource.com/c/go/+/671255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn>
2025-05-09crypto/tls: handle client hello version too highDaniel McCarney
If the client hello legacy version is >= TLS 1.3, and no supported_versions extension is sent, negotiate TLS 1.2 or lower when supported. On the topic of supported version negotiation RFC 8446 4.2.1 indicates TLS 1.3 implementations MUST send a supported_versions extension with a list of their supported protocol versions. The crypto/tls package enforces this when the client hello legacy version indicates TLS 1.3 (0x0304), aborting the handshake with an alertMissingExtension alert if no supported_versions were received. However, section 4.2.1 indicates different behaviour should be used when the extension is not present and TLS 1.2 or prior are supported: If this extension is not present, servers which are compliant with this specification and which also support TLS 1.2 MUST negotiate TLS 1.2 or prior as specified in [RFC5246], even if ClientHello.legacy_version is 0x0304 or later. This commit updates the client hello processing logic to allow this behaviour. If no supported_versions extension was received we ignore the legacy version being >= TLS 1.3 and instead negotiate a lower supported version if the server configuration allows. This fix in turn allows enabling the BoGo ClientHelloVersionTooHigh, MinorVersionTolerance, and MajorVersionTolerance tests. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/671235 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-09crypto/tls: fix TLS <1.3 client cert required alertDaniel McCarney
Previously for protocol versions older than TLS 1.3 our server handshake implementation sent an alertBadCertificate alert in the case where the server TLS config indicates a client cert is required and none was received. This commit updates the relevant logic to instead send alertHandshakeFailure in these circumstances. For TLS 1.2, RFC 5246 §7.4.6 unambiguously describes this as the correct alert: If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication, or respond with a fatal handshake_failure alert. The TLS 1.1 and 1.0 specs also describe using this alert (RFC 4346 §7.4.6 and RFC 2246 §7.4.6) both say: If client authentication is required by the server for the handshake to continue, it may respond with a fatal handshake failure alert. Making this correction also allows enabling the RequireAnyClientCertificate-TLS1* bogo tests. Updates #72006 Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/671195 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 07:47:42 +0000