aboutsummaryrefslogtreecommitdiff
path: root/src/crypto
AgeCommit message (Collapse)Author
20 hoursall: prealloc slice with possible minimum capabilitiesShulhan
4 dayscrypto/tls: fix ECH SNI encoded lengthNeal Patel
https://datatracker.ietf.org/doc/html/rfc9849#section-6.1.3 Change-Id: Ifccf7b92f69ddb9ae288991763111bd1f00e61de Reviewed-on: https://go-review.googlesource.com/c/go/+/765446 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
6 dayscrypto/internal/fips140/pbkdf2: fix typo in error messageNeal Patel
Change-Id: I24a44b0f06b02fe99c8364afa2a9c04ff5435c0e Reviewed-on: https://go-review.googlesource.com/c/go/+/765001 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Neal Patel <nealpatel@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org>
6 dayscrypto/internal/fips140/edwards25519/field: fix Invert commentFilippo Valsorda
Pointed out by Alexander Yastrebov in FiloSottile/edwards25519#48. Change-Id: I8ff0b761ff49ad454159f749e3e07ed86a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/745900 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Junyang Shao <shaojunyang@google.com> 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>
6 dayscrypto/internal/fips140/edwards25519: fix zero coeff. skip optimizationFilippo Valsorda
This was reported first by Adrian Grigore in private and then by github.com/shaharcohen1 in FiloSottile/edwards25519#53. fips140: off goos: linux goarch: amd64 pkg: crypto/internal/fips140/edwards25519 cpu: AMD EPYC 7443P 24-Core Processor │ 6837583eec │ 6837583eec-dirty │ │ sec/op │ sec/op vs base │ VarTimeDoubleScalarBaseMult-48 43.51µ ± 1% 42.92µ ± 0% -1.34% (p=0.000 n=100) Change-Id: I14523fc62732ae9233b8c198a3a626a36a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/745860 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> Reviewed-by: Junyang Shao <shaojunyang@google.com>
7 dayscrypto/tls: prevent deadlock when client sends multiple key update messagesRoland Shoemaker
When we made setReadTrafficSecret send an alert when there are pending handshake messages, we introduced a deadlock when the client sends multiple key update messages that request a response, as handleKeyUpdate will lock the mutex, and defer the unlocking until the end of the function, but setReadTrafficSecret called sendAlert in the failure case, which also tries to lock the mutex. Add an argument to setReadTrafficSecret which lets the caller indicate if the mutex is already locked, and if so, call sendAlertLocked instead of sendAlert. Thanks to Jakub Ciolek for reporting this issue. Fixes #78334 Fixes CVE-2026-32283 Change-Id: Id8e56974233c910e0d66ba96eafbd2ea57832610 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3881 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/763767 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: David Chase <drchase@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
7 dayscrypto/x509: fix wildcard constraint map case sensitivityRoland Shoemaker
When applying excluded constraints to wildcard DNS SANs, the constraint checking implementation did not normalize the case of the constraint nor the SAN, which could lead to incorrect constraint checking results. This change lowercases both the constraint and the SAN before checking for matches, ensuring that constraint checking is case-insensitive as intended. Thanks to Riyas from Saintgits College of Engineering for reporting this issue. Fixes #78332 Fixes CVE-2026-33810 Change-Id: Id27792c8ed4c40f2810bad8dbd8d5d520cb465bb Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3860 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/763763 Reviewed-by: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: David Chase <drchase@google.com>
8 dayscrypto/tls: avoid atLeastReader and associated allocations.Daniel Morsing
Go 1.21 introduced bytes.Buffer.AvailableBuffer. This mechanism lets us write directly into a Buffer's backing memory while also implementing custom logic without going through interfaces. atLeastReader caused an allocation on every read. On workloads with very small reads, these allocations can add up to substantial overhead. By using Buffer.AvailableBytes(), we can avoid these allocations and an interface indirection in the Read fast path. Fixes #58249. Change-Id: Icf26ec1dd7ef88154c47356ef9c26a516a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/739980 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
8 dayscrypto/ed25519: use FIPS 140-3 GenerateKey and enforce fips140=onlyFilippo Valsorda
Fixes #77594 Change-Id: I2685931ec37d9beb99de2e0398ab6f456a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/745800 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
12 dayscrypto/x509/pkix: avoid quadratic string concatenation in RDNSequence.StringNavtej
RDNSequence.String builds its result using repeated s += ... inside nested loops, leading to O(N²) time and memory complexity. A certificate with many Subject or Issuer RDN entries can therefore cause excessive CPU and memory usage when String is called. Switch to strings.Builder to construct the output, reducing complexity to O(N) without changing behavior. This follows the same approach used to fix CVE-2025-61729 (HostnameError.Error), which addressed the same quadratic concatenation pattern. Change-Id: Id44303b5732081de9f01d186bc2b8ac66349a650 GitHub-Last-Rev: b0706c20655d1a263c3a989b76c0c25796c900df GitHub-Pull-Request: golang/go#78265 Reviewed-on: https://go-review.googlesource.com/c/go/+/757680 Reviewed-by: Navtej Kathuria US <nkathuria@nvidia.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mateusz Poliwczak <mpoliwczak34@gmail.com>
2026-03-27crypto: disallow RegisterHash with hash value 0Roland Shoemaker
We already prevent registering hash values larger than the number of hashes we actually have, but for some reason we don't prevent registering hash value 0, which is the sentinel value we typically use for "no hash". This change adds a check to prevent registering hash value 0. Fixes #60548 Change-Id: Ifd6edffb22b268ef282eae1b2ae4cc0ce748776c Reviewed-on: https://go-review.googlesource.com/c/go/+/760280 Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-03-25crypto/x509: fix signature checking limitRoland Shoemaker
We added the "is this cert already in the chain" check (alreadyInChain) to considerCandidates before the signature limit. considerCandidates bails out when we exceed the signature check, but buildChains keeps calling considerCandidates until it exhausts all potential parents. In the case where a large number of certificates look to have signed each other (e.g. all have subject==issuerSubject and the same key), alreadyInChain is not particularly cheap, meaning even though we hit our "this is too much work" limit, we still do a lot of work. Move alreadyInChain after the signature limit, and also return a sentinel error, and check it in buildChains so we can break out of the loop early if we aren't actually going to do any more work. Thanks to Jakub Ciolek for reporting this issue. Fixes #78282 Fixes CVE-2026-32280 Change-Id: Ie6f05c6ba3b0a40c21f64f7c4f846e74fae3b10e Reviewed-on: https://go-review.googlesource.com/c/go/+/758320 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
2026-03-25crypto/x509: hoist policy pruning out of loopRoland Shoemaker
We only need to do this once, not once per mapping. Thanks to Jakub Ciolek for reporting this issue. Fixes #78281 Fixes CVE-2026-32281 Change-Id: Ic26f5f14d2a5e42ca8c24b8ae47bc3c5cc601863 Reviewed-on: https://go-review.googlesource.com/c/go/+/758061 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
2026-03-24cmd/compile: handle string literals in FIPS mode consistentlyCherry Mui
There are different code paths for compiling a composite literal, e.g. small vs. large, fully static vs. partially static. Following CL 755600, we need to apply the condition for string literals in FIPS mode consistently in all places. Enhance the test to check that not only does the code compile, the same code inside and outside of FIPS mode produce the same result. If the condition is not consistent in the compiler, it may compile the code, but not all the fields are actually assigned. Fixes #78173. Change-Id: Icaf673bd4798d4312d86c39b147d7fd33b9dae2c Reviewed-on: https://go-review.googlesource.com/c/go/+/756260 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-03-17cmd/compile: don't treat string literal as static data in FIPS modeCherry Mui
Reference a string literal requires a relocation, which is not allowed in static data in FIPS mode, as this would be an absolute relocation, and cannot be properly hashed at both link time and run time. Also, make sure the symbol's FIPS type is set before writing. This ensures relocations are checked in FIPS RODATA symbols. Currently we only call setFIPSType in prewrite if we change the type from a BSS type to a DATA type. But it is possible that the compiler sets the symbol type to RODATA and start writing to it. For #78173. Change-Id: I120a3b28ee3f38e9024479344565f54dff87d430 Reviewed-on: https://go-review.googlesource.com/c/go/+/755600 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Russ Cox <rsc@golang.org>
2026-03-17crypto/rsa: improve Precompute documentationFilippo Valsorda
Change-Id: Ibb76ee2532de959f8114a53f66c4070e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/755340 Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Nicholas Husin <husin@google.com> TryBot-Bypass: Roland Shoemaker <roland@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Nicholas Husin <nsh@golang.org>
2026-03-06crypto/x509: add more test cases for name constraints.Rudolf Polzer
This version of the code passes the tests, however, Go 1.25 currently fails. See I747e51edc16c1111f6a114de33af35f618793c90 for a backport of the test cases to Go 1.25 and a fix for the issue discovered there. Found as part of https://issues.chromium.org/issues/488306305 and related to issue #77968. Change-Id: I60fba0d635f23d53f2146cb64b9f6a29755712e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/750560 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>
2026-03-05crypto/x509: fix name constraint checking panicRoland Shoemaker
Apparently we allow empty dNSName SANs (e.g. a domain name of ""), which causes the excluded domain name wildcard checking to panic, because we assume names are always non-empty. RFC 5280 appears to say the empty string should not be accepted, although confusingly refers to this as " " (a single space). We should probably not allow that when creating certificates, and possibly when creating them as well (1.27 I guess). Thanks to Jakub Ciolek for reporting this issue. Fixes #77953 Fixes CVE-2026-27138 Change-Id: I4fb213a5450470969a7436cba09b71fd1755a6af Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3420 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/752183 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-03-05crypto/x509: fix full email constraint matchingRoland Shoemaker
For full email addresses (local@domain), we stored a map between the case sensitive local portion to the case insensitive domain portion, and used that to check if a email SAN matched the constraint. This could be abused, because it was a map[string]string, meaning if any two constraints had the same local portion but different domains, the second would overwrite the first. Change the map from map[string]string to map[rfc2821Mailbox]struct{}, where the domain portion of the mailbox is lowercased. When checking for a match we then check the parsed mailbox against the map, lowercasing the domain portion of the query when we initially parse the address. This gives us the same functionality as before, but without the possibility of one constraint overwriting another. Thanks to Jakub Ciolek for reporting this issue. Fixes #77952 Fixes CVE-2026-27137 Change-Id: Ia405209be6f3b87cf4ac220a645467418dc41805 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3440 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/752182 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Cherry Mui <cherryyz@google.com>
2026-02-26crypto/internal/boring: replace slice growth loop with slices.GrowRuss Cox
If dst is nil and len(plaintext) is 10MB, the slice growth loop allocates about 70MB. slices.Grow only allocates 10MB. Noticed on a real profile in a program built with boringcrypto. Change-Id: Iecc727b961273d4f2d553669d43014c507e25df8 Reviewed-on: https://go-review.googlesource.com/c/go/+/744400 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2026-02-23crypto/rand: remove exported fields in the default ReaderMateusz Poliwczak
Uses a clever trick with embeddeding such that, the Reader is 0-byte and does not have any exported fields. This change is not really a must, but I think it is better not to have any exported fields that could be accessed with reflect or such. Change-Id: Ib2e0b71d1e56b74a608601c98a81c8646a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/747460 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>
2026-02-17crypto: don't overwrite existing GODEBUG settingsqmuntal
Some tests set GODEBUG by calling t.Setenv("GODEBUG", "foo=bar"). This overwrites any existing GODEBUG settings, which is undesirable. Instead, append the new setting to any existing GODEBUG settings. As this operation is quite common, add a helper function testenv.SetGODEBUG to do this. Change-Id: Ie7905483e87ec4c4a448511a7dd53c18939577fd Reviewed-on: https://go-review.googlesource.com/c/go/+/734400 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com>
2026-02-12crypto/tls: fix CurvePreferences commentSimon Deziel
SecP256r1MLKEM768 appeared twice while the second should have been SecP384r1MLKEM1024. Change-Id: I0587b53248d2948fe7a33313871c39fe76251e9c GitHub-Last-Rev: de535819a33347feacfaa32d984ce58d206613d0 GitHub-Pull-Request: golang/go#77551 Reviewed-on: https://go-review.googlesource.com/c/go/+/744481 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2026-02-09crypto/sha1: provide optimised assembly for riscv64Julian Zhu
Provide an optimised assembly implementation of sha1 for riscv64. goos: linux goarch: riscv64 pkg: crypto/sha1 cpu: Spacemit(R) X60 │ oldsha1 │ newsha1 │ │ sec/op │ sec/op vs base │ Hash8Bytes/New-8 2.136µ ± 0% 1.173µ ± 0% -45.09% (p=0.000 n=8) Hash8Bytes/Sum-8 2.079µ ± 0% 1.116µ ± 0% -46.32% (p=0.000 n=8) Hash320Bytes/New-8 10.704µ ± 0% 4.954µ ± 0% -53.72% (p=0.000 n=8) Hash320Bytes/Sum-8 10.645µ ± 0% 4.872µ ± 0% -54.23% (p=0.000 n=8) Hash1K/New-8 29.66µ ± 0% 13.38µ ± 0% -54.90% (p=0.000 n=8) Hash1K/Sum-8 29.63µ ± 0% 13.24µ ± 0% -55.32% (p=0.000 n=8) Hash8K/New-8 226.8µ ± 1% 104.7µ ± 2% -53.84% (p=0.000 n=8) Hash8K/Sum-8 226.7µ ± 1% 102.9µ ± 1% -54.62% (p=0.000 n=8) geomean 19.72µ 9.387µ -52.40% │ oldsha1 │ newsha1 │ │ B/s │ B/s vs base │ Hash8Bytes/New-8 3.572Mi ± 0% 6.504Mi ± 0% +82.11% (p=0.000 n=8) Hash8Bytes/Sum-8 3.672Mi ± 0% 6.838Mi ± 0% +86.23% (p=0.000 n=8) Hash320Bytes/New-8 28.51Mi ± 0% 61.60Mi ± 0% +116.02% (p=0.000 n=8) Hash320Bytes/Sum-8 28.67Mi ± 0% 62.64Mi ± 0% +118.51% (p=0.000 n=8) Hash1K/New-8 32.92Mi ± 0% 73.00Mi ± 0% +121.74% (p=0.000 n=8) Hash1K/Sum-8 32.96Mi ± 0% 73.76Mi ± 0% +123.78% (p=0.000 n=8) Hash8K/New-8 34.44Mi ± 1% 74.61Mi ± 2% +116.61% (p=0.000 n=8) Hash8K/Sum-8 34.46Mi ± 1% 75.93Mi ± 1% +120.37% (p=0.000 n=8) geomean 18.51Mi 38.89Mi +110.07% Change-Id: I3d4d05fe19872412fdf77a337395e0bf84c41dd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/732560 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Joel Sing <joel@sing.id.au>
2026-02-09crypto/des: correct finalPermutation comment from 4-bit to 64-bitcuishuang
The finalPermutation array operates on a 64-bit preoutput block, not a 4-bit block. This updates the comment to accurately reflect the size of the data being processed in the DES algorithm's final permutation step. Change-Id: Ib6a5828a2e72d8bc8d04a3d413eaac320c15df15 Reviewed-on: https://go-review.googlesource.com/c/go/+/730020 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2026-02-09crypto/tls: update bogo versionRoland Shoemaker
Change-Id: Ia80dd969a2033328692d337ececef4e13986aa88 Reviewed-on: https://go-review.googlesource.com/c/go/+/726381 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Neal Patel <nealpatel@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-06crypto/tls: fix broken link in KeyLogWriter documentationkovan
The Mozilla developer documentation link for the NSS key log format has been broken since early 2022. Update the documentation to point to the IETF TLS working group draft which is currently in the RFC publication queue. Fixes #63331 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> Change-Id: I1a87cca839e503790170a6f3a48bef3b4c6bd624 Reviewed-on: https://go-review.googlesource.com/c/go/+/741444 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Sean Liao <sean@liao.dev> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev> Auto-Submit: Michael Pratt <mpratt@google.com>
2026-02-05crypto/tls: avoid data race when canceling a QUICConn's ContextDamien Neil
Methods on QUICConn are synchronous: The connection state is expected to change only in reaction to a user calling a QUICConn method, and the state change should finish completely before the method returns. The connection context provided to QUICConn.Start violates this model, because canceling the context causes an asynchronous state change. Prior to CL 719040, this caused no problems because canceling the context did not cause any user-visible state changes. In particular, canceling the context did not cause any new events to be immediately returned by QUICConn.NextEvent. CL 719040 introduced a new error event. Now, canceling a QUICConn's context causes a new connection event to be generated. Receiving this event causes a data race visible to the race detector, but the core problem is not the data race itself: It's that an asynchronous event (canceling the connection context) causes an change to the connection events. Fix this race by reworking the handling of QUICConn context cancellation a bit. We no longer react to cancellation while control of the connection lies with the user. We only process cancellation as part of a user call, such as QUICConn.Close or QUICConn.HandleData. Fixes #77274 Change-Id: If2e0f73618c4852114e0931b6bd0cb0b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/742561 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2026-02-03crypto/tls: revalidate whole chain on resumption on Windows and macOSFilippo Valsorda
TestHandshakeChangeRootCAsResumption and TestHandshakeGetConfigForClientDifferentClientCAs changed because previously rootA and rootB shared Subject and SPKI, which made the new full-chain revalidation check succeed, as the same leaf would verify against both roots. Fixes #77376 Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64-longtest Change-Id: I60bed694bdc621c9e83f1bd8a8224c016a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/741361 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> 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>
2026-02-02crypto/tls: document resumption behavior across ConfigsFilippo Valsorda
Updates #77113 Updates #77217 Updates CVE-2025-68121 Change-Id: Ia47904a9ed001275aad0243a6a0ce57e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/740240 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2026-02-02crypto/sha1: use const table for key loading on loong64Julian Zhu
Load constant keys from a static memory table rather than loading immediates into registers on loong64. Benchmark for Loongson-3A5000: goos: linux goarch: loong64 pkg: crypto/sha1 cpu: Loongson-3A5000-HV @ 2500.00MHz │ old │ new │ │ sec/op │ sec/op vs base │ Hash8Bytes/New-4 235.9n ± 0% 229.1n ± 0% -2.88% (p=0.000 n=8) Hash8Bytes/Sum-4 1.892µ ± 0% 1.882µ ± 0% -0.50% (p=0.000 n=8) Hash320Bytes/New-4 1022.0n ± 0% 963.8n ± 0% -5.70% (p=0.000 n=8) Hash320Bytes/Sum-4 1037.0n ± 0% 981.1n ± 0% -5.39% (p=0.000 n=8) Hash1K/New-4 2.760µ ± 0% 2.594µ ± 0% -6.01% (p=0.000 n=8) Hash1K/Sum-4 2.775µ ± 0% 2.610µ ± 0% -5.95% (p=0.000 n=8) Hash8K/New-4 20.46µ ± 0% 19.20µ ± 0% -6.17% (p=0.000 n=8) Hash8K/Sum-4 20.49µ ± 0% 19.22µ ± 0% -6.17% (p=0.000 n=8) geomean 2.498µ 2.377µ -4.87% │ old │ new │ │ B/s │ B/s vs base │ Hash8Bytes/New-4 32.34Mi ± 0% 33.30Mi ± 0% +2.98% (p=0.000 n=8) Hash8Bytes/Sum-4 4.034Mi ± 0% 4.053Mi ± 0% +0.47% (p=0.000 n=8) Hash320Bytes/New-4 298.7Mi ± 0% 316.7Mi ± 0% +6.02% (p=0.000 n=8) Hash320Bytes/Sum-4 294.3Mi ± 0% 311.0Mi ± 0% +5.69% (p=0.000 n=8) Hash1K/New-4 353.8Mi ± 0% 376.5Mi ± 0% +6.41% (p=0.000 n=8) Hash1K/Sum-4 351.9Mi ± 0% 374.1Mi ± 0% +6.31% (p=0.000 n=8) Hash8K/New-4 381.8Mi ± 0% 406.9Mi ± 0% +6.57% (p=0.000 n=8) Hash8K/Sum-4 381.4Mi ± 0% 406.4Mi ± 0% +6.58% (p=0.000 n=8) geomean 146.1Mi 153.6Mi +5.11% Change-Id: I7305caefa1434ab2bb4ce94a1c789d4ee5b7ccf3 Reviewed-on: https://go-review.googlesource.com/c/go/+/732580 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-30cmd/go,crypto/mlkem,crypto/x509,encoding/ascii85: clean up ↵Neal Patel
tautological/impossible nil conditions Change-Id: I3cdc599ebc93f5c9be5645e7ef7ce167242d9c1b Reviewed-on: https://go-review.googlesource.com/c/go/+/739800 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-28crypto/tls: check verifiedChains roots when resuming sessionsRoland Shoemaker
When resuming TLS sessions, on the server and client verify that the chains stored in the session state (verifiedChains) are still acceptable with regards to the Config by checking for the inclusion of the root in either ClientCAs (server) or RootCAs (client). This prevents resuming a session with a certificate chain that would be rejected during a full handshake due to an untrusted root. Updates #77113 Updates #77217 Updates CVE-2025-68121 Change-Id: I11fe00909ef1961c24ecf80bf5b97f7b1121d359 Reviewed-on: https://go-review.googlesource.com/c/go/+/737700 Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Coia Prant <coiaprant@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2026-01-28crypto/tls: add verifiedChains expiration checking during resumptionRoland Shoemaker
When resuming a session, check that the verifiedChains contain at least one chain that is still valid at the time of resumption. If not, trigger a new handshake. Updates #77113 Updates #77217 Updates CVE-2025-68121 Change-Id: I14f585c43da17802513cbdd5b10c552d7a38b34e Reviewed-on: https://go-review.googlesource.com/c/go/+/739321 Reviewed-by: Coia Prant <coiaprant@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-28Revert "crypto/tls: don't copy auto-rotated session ticket keys in Config.Clone"Roland Shoemaker
This reverts CL 736709 (commit bba24719a4cad5cc8d771fc9cfff5a38019d554a). Updates #77113 Updates CVE-2025-68121 Change-Id: I0261cb75e9adf9d0ac9890dc91ae8476b8988ba0 Reviewed-on: https://go-review.googlesource.com/c/go/+/739320 Reviewed-by: Coia Prant <coiaprant@gmail.com> 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>
2026-01-27crypto/subtle: add vector implementation of xorBytes for riscv64Joel Sing
On a Banana Pi F3: │ subtle.1 │ subtle.2 │ │ sec/op │ sec/op vs base │ ConstantTimeSelect-8 4.391n ± 1% 4.390n ± 0% ~ (p=0.500 n=10) ConstantTimeByteEq-8 3.763n ± 0% 3.764n ± 0% ~ (p=0.549 n=10) ConstantTimeEq-8 3.767n ± 1% 3.764n ± 0% -0.08% (p=0.002 n=10) ConstantTimeLessOrEq-8 3.136n ± 0% 3.138n ± 0% +0.06% (p=0.002 n=10) XORBytes/8Bytes-8 53.42n ± 0% 52.28n ± 0% -2.13% (p=0.000 n=10) XORBytes/128Bytes-8 64.79n ± 0% 64.12n ± 0% -1.03% (p=0.000 n=10) XORBytes/2048Bytes-8 479.3n ± 0% 322.0n ± 0% -32.84% (p=0.000 n=10) XORBytes/8192Bytes-8 8.897µ ± 26% 7.734µ ± 12% ~ (p=0.165 n=10) XORBytes/32768Bytes-8 39.17µ ± 17% 35.40µ ± 24% -9.63% (p=0.029 n=10) XORBytesAlignment/8Bytes0Offset-8 51.74n ± 0% 54.18n ± 0% +4.72% (p=0.000 n=10) XORBytesAlignment/8Bytes1Offset-8 51.51n ± 1% 53.52n ± 0% +3.92% (p=0.000 n=10) XORBytesAlignment/8Bytes2Offset-8 51.35n ± 1% 53.58n ± 0% +4.34% (p=0.000 n=10) XORBytesAlignment/8Bytes3Offset-8 50.86n ± 0% 53.56n ± 0% +5.31% (p=0.000 n=10) XORBytesAlignment/8Bytes4Offset-8 51.62n ± 0% 54.20n ± 0% +4.98% (p=0.000 n=10) XORBytesAlignment/8Bytes5Offset-8 51.42n ± 1% 53.48n ± 0% +4.02% (p=0.000 n=10) XORBytesAlignment/8Bytes6Offset-8 51.08n ± 1% 53.46n ± 0% +4.67% (p=0.000 n=10) XORBytesAlignment/8Bytes7Offset-8 50.83n ± 0% 53.54n ± 0% +5.33% (p=0.000 n=10) XORBytesAlignment/128Bytes0Offset-8 63.67n ± 0% 66.04n ± 0% +3.72% (p=0.000 n=10) XORBytesAlignment/128Bytes1Offset-8 114.40n ± 0% 67.42n ± 0% -41.07% (p=0.000 n=10) XORBytesAlignment/128Bytes2Offset-8 113.85n ± 0% 67.43n ± 0% -40.78% (p=0.000 n=10) XORBytesAlignment/128Bytes3Offset-8 114.60n ± 0% 67.31n ± 0% -41.27% (p=0.000 n=10) XORBytesAlignment/128Bytes4Offset-8 109.30n ± 0% 67.45n ± 0% -38.29% (p=0.000 n=10) XORBytesAlignment/128Bytes5Offset-8 110.70n ± 0% 67.32n ± 1% -39.19% (p=0.000 n=10) XORBytesAlignment/128Bytes6Offset-8 110.05n ± 0% 67.45n ± 1% -38.71% (p=0.000 n=10) XORBytesAlignment/128Bytes7Offset-8 110.60n ± 0% 67.43n ± 0% -39.04% (p=0.000 n=10) XORBytesAlignment/2048Bytes0Offset-8 478.4n ± 0% 335.6n ± 0% -29.85% (p=0.000 n=10) XORBytesAlignment/2048Bytes1Offset-8 529.7n ± 0% 349.3n ± 0% -34.05% (p=0.000 n=10) XORBytesAlignment/2048Bytes2Offset-8 529.3n ± 0% 349.8n ± 0% -33.91% (p=0.000 n=10) XORBytesAlignment/2048Bytes3Offset-8 529.8n ± 0% 349.5n ± 0% -34.02% (p=0.000 n=10) XORBytesAlignment/2048Bytes4Offset-8 524.7n ± 0% 349.6n ± 0% -33.38% (p=0.000 n=10) XORBytesAlignment/2048Bytes5Offset-8 525.9n ± 0% 349.6n ± 0% -33.52% (p=0.000 n=10) XORBytesAlignment/2048Bytes6Offset-8 525.1n ± 0% 349.8n ± 0% -33.39% (p=0.000 n=10) XORBytesAlignment/2048Bytes7Offset-8 526.0n ± 0% 349.8n ± 0% -33.51% (p=0.000 n=10) geomean 120.0n 96.92n -19.23% │ subtle.1 │ subtle.2 │ │ B/s │ B/s vs base │ XORBytes/8Bytes-8 142.8Mi ± 0% 145.9Mi ± 0% +2.19% (p=0.000 n=10) XORBytes/128Bytes-8 1.840Gi ± 0% 1.859Gi ± 0% +1.05% (p=0.000 n=10) XORBytes/2048Bytes-8 3.979Gi ± 0% 5.925Gi ± 0% +48.89% (p=0.000 n=10) XORBytes/8192Bytes-8 879.1Mi ± 35% 1010.2Mi ± 13% ~ (p=0.165 n=10) XORBytes/32768Bytes-8 797.9Mi ± 21% 882.8Mi ± 31% +10.64% (p=0.029 n=10) XORBytesAlignment/8Bytes0Offset-8 147.5Mi ± 0% 140.8Mi ± 0% -4.50% (p=0.000 n=10) XORBytesAlignment/8Bytes1Offset-8 148.1Mi ± 1% 142.5Mi ± 0% -3.77% (p=0.000 n=10) XORBytesAlignment/8Bytes2Offset-8 148.6Mi ± 1% 142.4Mi ± 0% -4.15% (p=0.000 n=10) XORBytesAlignment/8Bytes3Offset-8 150.0Mi ± 0% 142.4Mi ± 0% -5.04% (p=0.000 n=10) XORBytesAlignment/8Bytes4Offset-8 147.8Mi ± 0% 140.8Mi ± 0% -4.75% (p=0.000 n=10) XORBytesAlignment/8Bytes5Offset-8 148.4Mi ± 1% 142.6Mi ± 0% -3.87% (p=0.000 n=10) XORBytesAlignment/8Bytes6Offset-8 149.4Mi ± 1% 142.7Mi ± 0% -4.45% (p=0.000 n=10) XORBytesAlignment/8Bytes7Offset-8 150.1Mi ± 0% 142.5Mi ± 0% -5.05% (p=0.000 n=10) XORBytesAlignment/128Bytes0Offset-8 1.872Gi ± 0% 1.805Gi ± 0% -3.59% (p=0.000 n=10) XORBytesAlignment/128Bytes1Offset-8 1.042Gi ± 0% 1.768Gi ± 0% +69.65% (p=0.000 n=10) XORBytesAlignment/128Bytes2Offset-8 1.047Gi ± 0% 1.768Gi ± 0% +68.80% (p=0.000 n=10) XORBytesAlignment/128Bytes3Offset-8 1.040Gi ± 0% 1.771Gi ± 0% +70.27% (p=0.000 n=10) XORBytesAlignment/128Bytes4Offset-8 1.090Gi ± 0% 1.767Gi ± 0% +62.08% (p=0.000 n=10) XORBytesAlignment/128Bytes5Offset-8 1.077Gi ± 0% 1.771Gi ± 1% +64.41% (p=0.000 n=10) XORBytesAlignment/128Bytes6Offset-8 1.083Gi ± 0% 1.767Gi ± 1% +63.17% (p=0.000 n=10) XORBytesAlignment/128Bytes7Offset-8 1.078Gi ± 0% 1.768Gi ± 0% +64.07% (p=0.000 n=10) XORBytesAlignment/2048Bytes0Offset-8 3.987Gi ± 0% 5.684Gi ± 0% +42.55% (p=0.000 n=10) XORBytesAlignment/2048Bytes1Offset-8 3.601Gi ± 0% 5.459Gi ± 0% +51.61% (p=0.000 n=10) XORBytesAlignment/2048Bytes2Offset-8 3.604Gi ± 0% 5.453Gi ± 0% +51.31% (p=0.000 n=10) XORBytesAlignment/2048Bytes3Offset-8 3.600Gi ± 0% 5.457Gi ± 0% +51.56% (p=0.000 n=10) XORBytesAlignment/2048Bytes4Offset-8 3.635Gi ± 0% 5.456Gi ± 0% +50.10% (p=0.000 n=10) XORBytesAlignment/2048Bytes5Offset-8 3.627Gi ± 0% 5.455Gi ± 0% +50.39% (p=0.000 n=10) XORBytesAlignment/2048Bytes6Offset-8 3.632Gi ± 0% 5.454Gi ± 0% +50.14% (p=0.000 n=10) XORBytesAlignment/2048Bytes7Offset-8 3.626Gi ± 0% 5.453Gi ± 0% +50.39% (p=0.000 n=10) geomean 881.0Mi 1.097Gi +27.51% Change-Id: Id7f9d87fe1ea39aa91ea7d3fd1ba20737f0dda3c Reviewed-on: https://go-review.googlesource.com/c/go/+/649657 Reviewed-by: Julian Zhu <jz531210@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-01-15crypto/tls: don't copy auto-rotated session ticket keys in Config.CloneRoland Shoemaker
Once a tls.Config is used, it is not safe to mutate. We provide the Clone method in order to allow users to copy and modify a Config that is in use. If Config.SessionTicketKey is not populated, and if Config.SetSessionTicketKeys has not been called, we automatically populate and rotate session ticket keys. Clone was previously copying these keys into the new Config, meaning that two Configs could share the same auto-rotated session ticket keys. This could allow sessions to be resumed across different Configs, which may have completely different configurations. This change updates Clone to not copy the auto-rotated session ticket keys. Additionally, when resuming a session, check that not just that the leaf certificate is unexpired, but that the entire certificate chain is still unexpired. Fixes #77113 Fixes CVE-2025-68121 Change-Id: I011df7329de83068d11b3f0c793763692d018a98 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3300 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/736709 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-14crypto/internal/fips140test: add ML-DSA to FIPS 140-3 functional testsFilippo Valsorda
Change-Id: I568d28d27d2bc55bbadcc678a2fcf9d36a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/731540 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-01-12crypto: use testenv.Executable(t) instead of os.Args[0] in testsFilippo Valsorda
Change-Id: Ib0ec1f05e51a4295a9369d6e8c6b61976a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/735260 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-01-09crypto/rsa: log key on test failureFilippo Valsorda
For #74326 Change-Id: If1e61db22c9e7192e5dd56cd36141e5b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/734640 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: Roland Shoemaker <roland@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2025-12-17crypto: rename fips140v2.0 to fips140v1.26Filippo Valsorda
Turns out we can't use non-v1 versions for the FIPS 140-3 module, so we decided to match the versioning of the Go release the module is frozen from. Change-Id: Ib5c13511a51f9930fcde86cd7e8bd39c6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/730740 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: Michael Knyszek <mknyszek@google.com>
2025-12-16crypto/internal/fips140only: test fips140=only modeFilippo Valsorda
Fixes #70514 Updates #70878 Change-Id: I6a6a46561d872c8f7e9ea333ff208064b0bd44c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/728506 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: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-12-16crypto/tls: reject trailing messages after client/server helloRoland Shoemaker
For TLS 1.3, after procesesing the server/client hello, if there isn't a CCS message, reject the trailing messages which were appended to the hello messages. This prevents an on-path attacker from injecting plaintext messages into the handshake. Additionally, check that we don't have any buffered messages before we switch the read traffic secret regardless, since any buffered messages would have been under an old key which is no longer appropriate. We also invert the ordering of setting the read/write secrets so that if we fail when changing the read secret we send the alert using the correct write secret. Fixes #76443 Fixes CVE-2025-61730 Change-Id: If6ba8ad16f48d5cd5db5574824062ad4244a5b52 Reviewed-on: https://go-review.googlesource.com/c/go/+/724120 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Coia Prant <coiaprant@gmail.com>
2025-12-11runtime: make goroutines inherit DIT state, don't lock to OS threadRoland Shoemaker
When we first implemented DIT (crypto/subtle.WithDataIndependentTiming), we made it so that enabling DIT on a goroutine would lock that goroutine to its current OS thread. This was done to ensure that the DIT state (which is per-thread) would not leak to other goroutines. We also did not make goroutines inherit the DIT state. This change makes goroutines inherit the DIT state from their parent at creation time. It also removes the OS thread locking when enabling DIT on a goroutine. Instead, we now set the DIT state on the OS thread in the scheduler whenever we switch to a goroutine that has DIT enabled, and we unset it when switching to a goroutine that has DIT disabled. We add a new field to G and M, ditEnabled, to track whether the G wants DIT enabled, and whether the M currently has DIT enabled, respectively. When the scheduler executes a goroutine, it checks these fields and enables/disables DIT on the thread as needed. Additionally, cgocallbackg is updated to check if DIT is enabled when being called from C, and sets the G and M fields accordingly. This ensures that if DIT was enabled/disabled in C, the correct state will be reflected in the Go runtime. The behavior as it currently stands is as follows: - The function passed to crypto/subtle.WithDataIndependentTiming will have DIT enabled. - Any goroutine created within that function will inherit DIT enabled for its lifetime. Any goroutine created from subquent goroutines will also inherit DIT enabled for their lifetimes. - Calling into a C function within from a goroutine with DIT enabled will have DIT enabled. - If the C code disables DIT, the goroutine will have DIT re-enabled when returning to Go. - If the C code enables DIT, the goroutine will have DIT disabled when returning to Go if it was not previously enabled. - Calling back into Go code from C will have DIT enabled if it was enabled when calling into C, or if the C code enabled it. Change-Id: I8e91e6df13bb88e56e1036e0e0e5f04efd8eebd3 Reviewed-on: https://go-review.googlesource.com/c/go/+/726382 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2025-12-10crypto: clean up subprocess-spawning testsFilippo Valsorda
Consistently use testenv.Command and testenv.Executable, avoid redundant testenv.Must, use testenv.CleanCmdEnv where the output is parsed, always log the output with a preceding newline, invoke tests with -v, and always use cmd.Environ() to preserve existing env. Change-Id: I647ff1a8b7d162e5e8df9424030fac446a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/728641 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> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-12-10crypto/hpke: apply fips140.WithoutEnforcement to ML-KEM+X25519 hybridFilippo Valsorda
Since it uses an Approved KEM (ML-KEM), the overall hybrid KEM is Approved, even if X25519 is not. Updates #70514 Updates #74630 Change-Id: I2bb60c36fcf570baa3c389e2daa3698e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/728505 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> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-12-10crypto/mlkem/mlkemtest: error out in fips140=only modeFilippo Valsorda
Updates #70514 Change-Id: I1d1a0b4a2c7ee4cb6e8e0700dd3463a46a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/728502 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-12-10crypto/hpke: don't corrupt enc's excess capacity in DHKEM decapFilippo Valsorda
Caught because the one-shop APIs put the ciphertext after enc in a single slice, so Recipient.Open would corrupt the ciphertext. Change-Id: I15fe1dfcc05a5a7f5cd0b4ada21661e66a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/728500 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-12-10crypto/internal/fips140/aes/gcm: don't panic on bad nonces out of FIPS 140-3 ↵Filippo Valsorda
mode The enforcement is good beyond compliance if it is correct, but I am more nervous about accidental DoS due to mismatches between how the caller calculates a nonce and how the enforcement expects it to be calculated. We need to have this enforcement in FIPS 140-3 mode, but no need to blow ourselves up when it's off. If all goes well, this code is unreachable anyway. Change-Id: If73ec59ebbd283b0e5506354961a87a06a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/728504 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> Reviewed-by: David Chase <drchase@google.com>
2025-12-10crypto/hpke: use new gcm.NewGCMForHPKE for FIPS 140-3 complianceFilippo Valsorda
It does the exact same thing, but we can document it as an allowed and enforced nonce scheme in the Security Policy. Change-Id: I9d95ba53354e5c8112cde24101570d4b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/728503 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> Auto-Submit: Filippo Valsorda <filippo@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 10:52:39 +0000