| Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The cpu/go-acvp repository holding trimmed ACVP test server vectors and
validated expected results was always meant to be a temporary home. It
has now been migrated to geomys/acvp-testdata where it will continue to
be maintained by Geomys along with the FIPS module.
This commit updates acvp_test.go to use the new module location.
Change-Id: I888b125356afd0b4073cb38645486c258dea3c54
Reviewed-on: https://go-review.googlesource.com/c/go/+/725620
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Several crypto functions accepting a rand parameter skip calling
boringcrypto when the rand is not boring.RandReader.
The new crypto/internal/rand package currently defines its own Reader
that wraps boring.RandReader. That will unintentionally bypass
boringcrypto when used with the aforementioned functions.
Fixes #76672
Change-Id: Ie0c1345530c734a23815f9593590b5d32604f54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/726220
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: 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>
|
|
First, we centralize all random bytes generation through drbg.Read. The
rest of the FIPS 140-3 module can't use external functions anyway, so
drbg.Read needs to have all the logic.
Then, make sure that the crypto/... tree uses drbg.Read (or the new
crypto/internal/rand.Reader wrapper) instead of crypto/rand, so it is
unaffected by applications setting crypto/rand.Reader.
Next, pass all unspecified random io.Reader parameters through the new
crypto/internal/rand.CustomReader, which just redirects to drbg.Read
unless GODEBUG=cryptocustomrand=1 is set. Move all the calls to
MaybeReadByte there, since it's only needed for these custom Readers.
Finally, add testing/cryptotest.SetGlobalRandom which sets
crypto/rand.Reader to a locked deterministic source and overrides
drbg.Read. This way SetGlobalRandom should affect all cryptographic
randomness in the standard library.
Fixes #70942
Co-authored-by: qiulaidongfeng <2645477756@qq.com>
Change-Id: I6a6a69641311d9fac318abcc6d79677f0e406100
Reviewed-on: https://go-review.googlesource.com/c/go/+/724480
Reviewed-by: Nicholas Husin <nsh@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
WithoutEnforcement lets programs running under GODEBUG=fips140=only
selectively opt out of strict enforcement. This is especially helpful
for non-critical uses of cryptography routines like SHA-1 for content
addressable storage backends (E.g. git).
Fixes #74630
Change-Id: Iabba1f5eb63498db98047aca45e09c5dccf2fbdf
Reviewed-on: https://go-review.googlesource.com/c/go/+/723720
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
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>
|
|
Implement overflow-aware optimization in ctrBlocks8Asm: make a fast branch
in case when there is no overflow. One branch per 8 blocks is faster than
7 increments in general purpose registers and transfers from them to XMM.
Added AES-192 and AES-256 modes to the AES-CTR benchmark.
Added a correctness test in ctr_test.go for the overflow optimization.
This improves performance, especially in AES-128 mode.
goos: windows
goarch: amd64
pkg: crypto/cipher
cpu: AMD Ryzen 7 5800H with Radeon Graphics
│ B/s │ B/s vs base
AESCTR/128/50-16 1.377Gi ± 0% 1.384Gi ± 0% +0.51% (p=0.028 n=20)
AESCTR/128/1K-16 6.164Gi ± 0% 6.892Gi ± 1% +11.81% (p=0.000 n=20)
AESCTR/128/8K-16 7.372Gi ± 0% 8.768Gi ± 1% +18.95% (p=0.000 n=20)
AESCTR/192/50-16 1.289Gi ± 0% 1.279Gi ± 0% -0.75% (p=0.001 n=20)
AESCTR/192/1K-16 5.734Gi ± 0% 6.011Gi ± 0% +4.83% (p=0.000 n=20)
AESCTR/192/8K-16 6.889Gi ± 1% 7.437Gi ± 0% +7.96% (p=0.000 n=20)
AESCTR/256/50-16 1.170Gi ± 0% 1.163Gi ± 0% -0.54% (p=0.005 n=20)
AESCTR/256/1K-16 5.235Gi ± 0% 5.391Gi ± 0% +2.98% (p=0.000 n=20)
AESCTR/256/8K-16 6.361Gi ± 0% 6.676Gi ± 0% +4.94% (p=0.000 n=20)
geomean 3.681Gi 3.882Gi +5.46%
The slight slowdown on 50-byte workloads is unrelated to this change,
because such workloads never use ctrBlocks8Asm.
Updates #76061
Change-Id: Idfd628ac8bb282d9c73c6adf048eb12274a41379
GitHub-Last-Rev: 5aadd39351806fbbf5201e07511aac05bdcb0529
GitHub-Pull-Request: golang/go#76059
Reviewed-on: https://go-review.googlesource.com/c/go/+/714361
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: AHMAD ابو وليد <mizommz@gmail.com>
Reviewed-by: 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>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
|
|
First, this adds a GCM mode for QUIC, and a generic TLS 1.3/QUIC-like
XOR'd counter mode. QUIC constructs nonces exactly like TLS 1.3, but the
counter does not reset to zero on a key update, so the mask must be
provided explicitly (or we will panic well before running out of
counters because the wrong value is XOR'd out). See the analysis at
https://github.com/quic-go/quic-go/issues/5077#issuecomment-3570352683
for the details of QUIC and FIPS 140-3 compliance (including a
workaround for the key update issue).
Second, this coalesces all the compliance modes around two schemes:
fixed || counter, and fixed XOR counter. The former is used in TLS 1.2
and SSH, and the latter is used in TLS 1.3 and QUIC.
This would not be a backwards compatible change if these were public
APIs, but we only need different versions of the FIPS 140-3 module to be
source-compatible with the standard library, and the callers of these
NewGCMFor* functions only care that the return value implements
cipher.AEAD, at least for now.
This exposes no new public APIs, but lets us get started validating
these functions in v2.0.0 of the FIPS 140-3 module.
Updates #73110
Change-Id: I3d86cf8a3c4a96caf361c29f0db5f9706a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/723760
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I71d63b0b78a9fc4895574f6df465e22c9585e77c
Reviewed-on: https://go-review.googlesource.com/c/go/+/710196
Reviewed-by: 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>
|
|
speed-up
goos: linux
goarch: amd64
pkg: crypto/sha512
cpu: AMD EPYC 7B13
│ before │ after │
│ sec/op │ sec/op vs base │
Hash8Bytes/New 486.7n ± 1% 440.3n ± 0% -9.53% (p=0.001 n=7)
Hash8Bytes/New-2 487.3n ± 1% 442.6n ± 1% -9.17% (p=0.001 n=7)
Hash8Bytes/New-4 488.0n ± 1% 442.3n ± 0% -9.36% (p=0.001 n=7)
Hash8Bytes/Sum384 495.1n ± 0% 451.2n ± 1% -8.87% (p=0.001 n=7)
Hash8Bytes/Sum384-2 495.0n ± 1% 450.8n ± 1% -8.93% (p=0.001 n=7)
Hash8Bytes/Sum384-4 500.2n ± 2% 453.6n ± 2% -9.32% (p=0.001 n=7)
Hash8Bytes/Sum512 497.3n ± 1% 452.1n ± 0% -9.09% (p=0.001 n=7)
Hash8Bytes/Sum512-2 496.0n ± 1% 453.5n ± 0% -8.57% (p=0.001 n=7)
Hash8Bytes/Sum512-4 498.5n ± 0% 452.3n ± 1% -9.27% (p=0.001 n=7)
Hash1K/New 3.985µ ± 1% 3.543µ ± 1% -11.09% (p=0.001 n=7)
Hash1K/New-2 4.004µ ± 2% 3.558µ ± 1% -11.14% (p=0.001 n=7)
Hash1K/New-4 3.997µ ± 0% 3.563µ ± 1% -10.86% (p=0.001 n=7)
Hash1K/Sum384 3.996µ ± 1% 3.560µ ± 1% -10.91% (p=0.001 n=7)
Hash1K/Sum384-2 4.011µ ± 1% 3.576µ ± 1% -10.85% (p=0.001 n=7)
Hash1K/Sum384-4 4.004µ ± 0% 3.564µ ± 0% -10.99% (p=0.001 n=7)
Hash1K/Sum512 3.998µ ± 1% 3.555µ ± 1% -11.08% (p=0.001 n=7)
Hash1K/Sum512-2 3.996µ ± 0% 3.560µ ± 1% -10.91% (p=0.001 n=7)
Hash1K/Sum512-4 4.004µ ± 1% 3.573µ ± 1% -10.76% (p=0.001 n=7)
Hash8K/New 28.34µ ± 1% 25.29µ ± 1% -10.77% (p=0.001 n=7)
Hash8K/New-2 28.45µ ± 1% 25.48µ ± 1% -10.44% (p=0.001 n=7)
Hash8K/New-4 28.42µ ± 1% 25.37µ ± 1% -10.71% (p=0.001 n=7)
Hash8K/Sum384 28.38µ ± 0% 25.18µ ± 0% -11.28% (p=0.001 n=7)
Hash8K/Sum384-2 28.50µ ± 1% 25.35µ ± 1% -11.07% (p=0.001 n=7)
Hash8K/Sum384-4 28.51µ ± 1% 25.35µ ± 0% -11.07% (p=0.001 n=7)
Hash8K/Sum512 28.34µ ± 1% 25.23µ ± 0% -10.96% (p=0.001 n=7)
Hash8K/Sum512-2 28.33µ ± 1% 25.23µ ± 1% -10.95% (p=0.001 n=7)
Hash8K/Sum512-4 28.48µ ± 1% 25.31µ ± 1% -11.13% (p=0.001 n=7)
geomean 3.828µ 3.433µ -10.34%
│ before │ after │
│ B/s │ B/s vs base │
Hash8Bytes/New 15.68Mi ± 1% 17.33Mi ± 0% +10.52% (p=0.001 n=7)
Hash8Bytes/New-2 15.66Mi ± 1% 17.23Mi ± 1% +10.05% (p=0.001 n=7)
Hash8Bytes/New-4 15.63Mi ± 0% 17.25Mi ± 0% +10.37% (p=0.001 n=7)
Hash8Bytes/Sum384 15.41Mi ± 0% 16.91Mi ± 1% +9.72% (p=0.001 n=7)
Hash8Bytes/Sum384-2 15.41Mi ± 1% 16.93Mi ± 1% +9.84% (p=0.001 n=7)
Hash8Bytes/Sum384-4 15.25Mi ± 2% 16.82Mi ± 2% +10.32% (p=0.001 n=7)
Hash8Bytes/Sum512 15.34Mi ± 1% 16.87Mi ± 0% +9.94% (p=0.001 n=7)
Hash8Bytes/Sum512-2 15.38Mi ± 1% 16.82Mi ± 0% +9.36% (p=0.001 n=7)
Hash8Bytes/Sum512-4 15.31Mi ± 0% 16.87Mi ± 1% +10.22% (p=0.001 n=7)
Hash1K/New 245.0Mi ± 1% 275.6Mi ± 1% +12.47% (p=0.001 n=7)
Hash1K/New-2 243.9Mi ± 2% 274.5Mi ± 1% +12.55% (p=0.001 n=7)
Hash1K/New-4 244.3Mi ± 0% 274.1Mi ± 1% +12.21% (p=0.001 n=7)
Hash1K/Sum384 244.4Mi ± 0% 274.3Mi ± 1% +12.24% (p=0.001 n=7)
Hash1K/Sum384-2 243.5Mi ± 1% 273.1Mi ± 1% +12.16% (p=0.001 n=7)
Hash1K/Sum384-4 243.9Mi ± 0% 274.0Mi ± 0% +12.35% (p=0.001 n=7)
Hash1K/Sum512 244.3Mi ± 1% 274.7Mi ± 1% +12.46% (p=0.001 n=7)
Hash1K/Sum512-2 244.4Mi ± 0% 274.3Mi ± 1% +12.25% (p=0.001 n=7)
Hash1K/Sum512-4 243.9Mi ± 1% 273.3Mi ± 1% +12.08% (p=0.001 n=7)
Hash8K/New 275.7Mi ± 1% 309.0Mi ± 1% +12.07% (p=0.001 n=7)
Hash8K/New-2 274.6Mi ± 1% 306.6Mi ± 1% +11.67% (p=0.001 n=7)
Hash8K/New-4 274.9Mi ± 1% 307.9Mi ± 1% +11.99% (p=0.001 n=7)
Hash8K/Sum384 275.3Mi ± 0% 310.3Mi ± 0% +12.71% (p=0.001 n=7)
Hash8K/Sum384-2 274.1Mi ± 1% 308.2Mi ± 1% +12.45% (p=0.001 n=7)
Hash8K/Sum384-4 274.1Mi ± 1% 308.2Mi ± 0% +12.44% (p=0.001 n=7)
Hash8K/Sum512 275.7Mi ± 1% 309.6Mi ± 0% +12.31% (p=0.001 n=7)
Hash8K/Sum512-2 275.8Mi ± 1% 309.7Mi ± 1% +12.29% (p=0.001 n=7)
Hash8K/Sum512-4 274.3Mi ± 1% 308.7Mi ± 1% +12.52% (p=0.001 n=7)
geomean 101.2Mi 112.9Mi +11.53%
│ before │ after │
│ B/op │ B/op vs base │
Hash8Bytes/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum384 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum384-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum384-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum512 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum512-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum512-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum384 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum384-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum384-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum512 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum512-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum512-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum384 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum384-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum384-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum512 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum512-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum512-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
geomean ² +0.00% ²
¹ all samples are equal
² summaries must be >0 to compute geomean
│ before │ after │
│ allocs/op │ allocs/op vs base │
Hash8Bytes/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum384 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum384-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum384-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum512 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum512-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum512-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum384 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum384-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum384-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum512 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum512-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum512-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum384 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum384-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum384-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum512 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum512-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum512-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
geomean ² +0.00% ²
¹ all samples are equal
² summaries must be >0 to compute geomean
Change-Id: I3791244b3f69e093203f6aa46dc59428afcb9223
Reviewed-on: https://go-review.googlesource.com/c/go/+/711844
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
|
|
speed-up
goos: linux
goarch: amd64
pkg: crypto/sha256
cpu: AMD EPYC 7B13
│ before │ after │
│ sec/op │ sec/op vs base │
Hash8Bytes/New 384.4n ± 2% 347.2n ± 0% -9.68% (p=0.001 n=7)
Hash8Bytes/New-2 386.3n ± 2% 348.3n ± 1% -9.84% (p=0.001 n=7)
Hash8Bytes/New-4 386.7n ± 1% 347.9n ± 1% -10.03% (p=0.001 n=7)
Hash8Bytes/Sum224 406.9n ± 2% 358.8n ± 3% -11.82% (p=0.001 n=7)
Hash8Bytes/Sum224-2 404.1n ± 1% 359.8n ± 1% -10.96% (p=0.001 n=7)
Hash8Bytes/Sum224-4 409.5n ± 1% 360.9n ± 1% -11.87% (p=0.001 n=7)
Hash8Bytes/Sum256 401.3n ± 1% 352.4n ± 0% -12.19% (p=0.001 n=7)
Hash8Bytes/Sum256-2 402.0n ± 1% 354.2n ± 1% -11.89% (p=0.001 n=7)
Hash8Bytes/Sum256-4 403.7n ± 1% 353.5n ± 1% -12.43% (p=0.001 n=7)
Hash1K/New 5.836µ ± 1% 5.180µ ± 2% -11.24% (p=0.001 n=7)
Hash1K/New-2 5.855µ ± 1% 5.177µ ± 5% -11.58% (p=0.001 n=7)
Hash1K/New-4 5.878µ ± 0% 5.215µ ± 3% -11.28% (p=0.001 n=7)
Hash1K/Sum224 5.860µ ± 1% 5.225µ ± 1% -10.84% (p=0.001 n=7)
Hash1K/Sum224-2 5.852µ ± 1% 5.198µ ± 1% -11.18% (p=0.001 n=7)
Hash1K/Sum224-4 5.867µ ± 1% 5.226µ ± 4% -10.93% (p=0.001 n=7)
Hash1K/Sum256 5.851µ ± 0% 5.246µ ± 1% -10.34% (p=0.001 n=7)
Hash1K/Sum256-2 5.863µ ± 1% 5.237µ ± 2% -10.68% (p=0.001 n=7)
Hash1K/Sum256-4 5.873µ ± 1% 5.191µ ± 1% -11.61% (p=0.001 n=7)
Hash8K/New 44.06µ ± 0% 38.93µ ± 1% -11.63% (p=0.001 n=7)
Hash8K/New-2 44.23µ ± 0% 39.14µ ± 1% -11.50% (p=0.001 n=7)
Hash8K/New-4 44.25µ ± 1% 39.04µ ± 1% -11.77% (p=0.001 n=7)
Hash8K/Sum224 43.98µ ± 1% 40.47µ ± 2% -7.98% (p=0.001 n=7)
Hash8K/Sum224-2 44.31µ ± 1% 39.54µ ± 3% -10.76% (p=0.001 n=7)
Hash8K/Sum224-4 44.45µ ± 1% 39.04µ ± 2% -12.16% (p=0.001 n=7)
Hash8K/Sum256 43.95µ ± 0% 39.23µ ± 0% -10.75% (p=0.001 n=7)
Hash8K/Sum256-2 44.19µ ± 1% 39.39µ ± 2% -10.87% (p=0.001 n=7)
Hash8K/Sum256-4 44.19µ ± 1% 39.27µ ± 1% -11.13% (p=0.001 n=7)
Hash256K/New 1.397m ± 1% 1.238m ± 1% -11.39% (p=0.001 n=7)
Hash256K/New-2 1.404m ± 1% 1.242m ± 1% -11.53% (p=0.001 n=7)
Hash256K/New-4 1.402m ± 1% 1.243m ± 1% -11.31% (p=0.001 n=7)
Hash256K/Sum224 1.398m ± 0% 1.237m ± 1% -11.48% (p=0.001 n=7)
Hash256K/Sum224-2 1.402m ± 1% 1.239m ± 1% -11.59% (p=0.001 n=7)
Hash256K/Sum224-4 1.409m ± 1% 1.245m ± 1% -11.61% (p=0.001 n=7)
Hash256K/Sum256 1.402m ± 1% 1.242m ± 1% -11.38% (p=0.001 n=7)
Hash256K/Sum256-2 1.397m ± 1% 1.240m ± 1% -11.22% (p=0.001 n=7)
Hash256K/Sum256-4 1.404m ± 1% 1.250m ± 1% -10.97% (p=0.001 n=7)
Hash1M/New 5.584m ± 2% 4.944m ± 1% -11.46% (p=0.001 n=7)
Hash1M/New-2 5.609m ± 1% 4.974m ± 1% -11.33% (p=0.001 n=7)
Hash1M/New-4 5.625m ± 2% 4.984m ± 2% -11.40% (p=0.001 n=7)
Hash1M/Sum224 5.578m ± 0% 4.949m ± 0% -11.28% (p=0.001 n=7)
Hash1M/Sum224-2 5.603m ± 1% 4.985m ± 1% -11.02% (p=0.001 n=7)
Hash1M/Sum224-4 5.619m ± 1% 4.976m ± 1% -11.44% (p=0.001 n=7)
Hash1M/Sum256 5.589m ± 1% 4.940m ± 0% -11.61% (p=0.001 n=7)
Hash1M/Sum256-2 5.581m ± 1% 4.981m ± 1% -10.75% (p=0.001 n=7)
Hash1M/Sum256-4 5.618m ± 3% 4.966m ± 1% -11.59% (p=0.001 n=7)
geomean 60.48µ 53.71µ -11.19%
│ before │ after │
│ B/s │ B/s vs base │
Hash8Bytes/New 19.85Mi ± 2% 21.97Mi ± 0% +10.72% (p=0.001 n=7)
Hash8Bytes/New-2 19.75Mi ± 2% 21.91Mi ± 1% +10.91% (p=0.001 n=7)
Hash8Bytes/New-4 19.73Mi ± 1% 21.93Mi ± 1% +11.16% (p=0.001 n=7)
Hash8Bytes/Sum224 18.75Mi ± 2% 21.27Mi ± 3% +13.43% (p=0.001 n=7)
Hash8Bytes/Sum224-2 18.88Mi ± 1% 21.20Mi ± 1% +12.27% (p=0.001 n=7)
Hash8Bytes/Sum224-4 18.63Mi ± 1% 21.14Mi ± 1% +13.46% (p=0.001 n=7)
Hash8Bytes/Sum256 19.01Mi ± 1% 21.65Mi ± 0% +13.90% (p=0.001 n=7)
Hash8Bytes/Sum256-2 18.98Mi ± 1% 21.54Mi ± 1% +13.52% (p=0.001 n=7)
Hash8Bytes/Sum256-4 18.90Mi ± 1% 21.58Mi ± 1% +14.18% (p=0.001 n=7)
Hash1K/New 167.4Mi ± 1% 188.5Mi ± 2% +12.65% (p=0.001 n=7)
Hash1K/New-2 166.8Mi ± 1% 188.6Mi ± 5% +13.11% (p=0.001 n=7)
Hash1K/New-4 166.1Mi ± 0% 187.3Mi ± 3% +12.71% (p=0.001 n=7)
Hash1K/Sum224 166.7Mi ± 1% 186.9Mi ± 1% +12.14% (p=0.001 n=7)
Hash1K/Sum224-2 166.9Mi ± 1% 187.9Mi ± 1% +12.59% (p=0.001 n=7)
Hash1K/Sum224-4 166.5Mi ± 1% 186.9Mi ± 4% +12.27% (p=0.001 n=7)
Hash1K/Sum256 166.9Mi ± 0% 186.1Mi ± 1% +11.51% (p=0.001 n=7)
Hash1K/Sum256-2 166.6Mi ± 1% 186.5Mi ± 2% +11.94% (p=0.001 n=7)
Hash1K/Sum256-4 166.3Mi ± 1% 188.1Mi ± 1% +13.15% (p=0.001 n=7)
Hash8K/New 177.3Mi ± 0% 200.7Mi ± 1% +13.17% (p=0.001 n=7)
Hash8K/New-2 176.6Mi ± 0% 199.6Mi ± 1% +13.00% (p=0.001 n=7)
Hash8K/New-4 176.6Mi ± 1% 200.1Mi ± 1% +13.34% (p=0.001 n=7)
Hash8K/Sum224 177.6Mi ± 1% 193.0Mi ± 2% +8.67% (p=0.001 n=7)
Hash8K/Sum224-2 176.3Mi ± 1% 197.6Mi ± 3% +12.06% (p=0.001 n=7)
Hash8K/Sum224-4 175.8Mi ± 1% 200.1Mi ± 2% +13.84% (p=0.001 n=7)
Hash8K/Sum256 177.8Mi ± 0% 199.2Mi ± 0% +12.04% (p=0.001 n=7)
Hash8K/Sum256-2 176.8Mi ± 1% 198.4Mi ± 2% +12.20% (p=0.001 n=7)
Hash8K/Sum256-4 176.8Mi ± 1% 198.9Mi ± 1% +12.52% (p=0.001 n=7)
Hash256K/New 179.0Mi ± 1% 202.0Mi ± 1% +12.86% (p=0.001 n=7)
Hash256K/New-2 178.1Mi ± 1% 201.3Mi ± 1% +13.03% (p=0.001 n=7)
Hash256K/New-4 178.4Mi ± 1% 201.1Mi ± 1% +12.76% (p=0.001 n=7)
Hash256K/Sum224 178.8Mi ± 0% 202.0Mi ± 1% +12.97% (p=0.001 n=7)
Hash256K/Sum224-2 178.3Mi ± 1% 201.7Mi ± 1% +13.11% (p=0.001 n=7)
Hash256K/Sum224-4 177.5Mi ± 1% 200.8Mi ± 1% +13.13% (p=0.001 n=7)
Hash256K/Sum256 178.3Mi ± 1% 201.2Mi ± 1% +12.83% (p=0.001 n=7)
Hash256K/Sum256-2 179.0Mi ± 1% 201.6Mi ± 1% +12.64% (p=0.001 n=7)
Hash256K/Sum256-4 178.0Mi ± 1% 200.0Mi ± 1% +12.33% (p=0.001 n=7)
Hash1M/New 179.1Mi ± 2% 202.3Mi ± 1% +12.94% (p=0.001 n=7)
Hash1M/New-2 178.3Mi ± 1% 201.1Mi ± 1% +12.78% (p=0.001 n=7)
Hash1M/New-4 177.8Mi ± 2% 200.6Mi ± 2% +12.87% (p=0.001 n=7)
Hash1M/Sum224 179.3Mi ± 0% 202.1Mi ± 0% +12.71% (p=0.001 n=7)
Hash1M/Sum224-2 178.5Mi ± 1% 200.6Mi ± 1% +12.39% (p=0.001 n=7)
Hash1M/Sum224-4 178.0Mi ± 1% 201.0Mi ± 1% +12.92% (p=0.001 n=7)
Hash1M/Sum256 178.9Mi ± 1% 202.4Mi ± 0% +13.13% (p=0.001 n=7)
Hash1M/Sum256-2 179.2Mi ± 1% 200.8Mi ± 1% +12.04% (p=0.001 n=7)
Hash1M/Sum256-4 178.0Mi ± 3% 201.3Mi ± 1% +13.12% (p=0.001 n=7)
geomean 112.5Mi 126.6Mi +12.60%
│ before │ after │
│ B/op │ B/op vs base │
Hash8Bytes/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
geomean ² +0.00% ²
¹ all samples are equal
² summaries must be >0 to compute geomean
│ before │ after │
│ allocs/op │ allocs/op vs base │
Hash8Bytes/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8Bytes/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1K/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash8K/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash256K/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/New 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/New-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/New-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum224 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum224-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum224-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum256 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum256-2 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
Hash1M/Sum256-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=7) ¹
geomean ² +0.00% ²
¹ all samples are equal
² summaries must be >0 to compute geomean
Change-Id: I705f024221690532b2e891ab8e508d07eefe295b
Reviewed-on: https://go-review.googlesource.com/c/go/+/711843
Reviewed-by: 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>
|
|
addMulVVWx assembly routine is used to multiply bignum multiplicand with a 64-bit multiplier.
The new implementation for s390x architecture uses an algorithm based on vector instructions,
with a significant performance improvement.
Note: z13 is the minimum architecture for Go, which already has VX support.
The performance improvement is as below:
goos: linux
goarch: s390x
pkg: crypto/internal/fips140/bigmod
Orig.txt Vector_Patch.txt
sec/op sec/op vs base
ModAdd 164.1n ± 0% 159.7n ± 0% -2.7% (p=0.000 n=10)
ModSub 152.3n ± 1% 147.3n ± 0% -3.25 (p=0.000 n=10)
MontgomeryRepr 4.806µ ± 3% 1.829µ ± 0% -61.94% (p=0.000 n=10)
MontgomeryMul 4.812µ ± 5% 1.834µ ± 0% -61.90% (p=0.000 n=10)
ModMul 9.646µ ± 3% 3.698µ ± 0% -61.67% (p=0.000 n=10)
ExpBig 11.28m ± 0% 11.28m ± 0% +0.04 (p=0.035 n=10)
Exp 12.284m ± 5% 5.004m ± 1% -59.26 (p=0.000 n=10)
geomean 18.61µ 10.74µ -42.2
Change-Id: I679944c9dac9f43f1626b018f72efa6da0d2442d
Cq-Include-Trybots: luci.golang.try:gotip-linux-s390x
Reviewed-on: https://go-review.googlesource.com/c/go/+/716480
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Vishwanatha HD <vishwanatha.hd@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Srinivas Pokala <Pokala.Srinivas@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Consider a hypothetical SumCSHAKE256 function:
func SumCSHAKE256(N, S, data []byte, length int) []byte {
out := make([]byte, 64)
return sumCSHAKE256(out, N, S, data, length)
}
func sumCSHAKE256(out, N, S, data []byte, length int) []byte {
if len(out) < length {
out = make([]byte, length)
} else {
out = out[:length]
}
h := sha3.NewCSHAKE256(N, S)
h.Write(data)
h.Read(out)
return out
}
Currently this has 4 allocations:
- one for out (unless stack allocated),
- one for the SHAKE result of crypto/internal/fips140/sha3.newCShake,
- one for the initBlock allocation in crypto/internal/fips140/sha3.newCShake,
- one for the result of crypto/internal/fips140/sha3.bytepad.
We eliminate the SHAKE allocation by outlining the SHAKE allocation in
crypto/internal/fips140/sha3.NewCSHAKE128 and NewCSHAKE256. As
crypto/sha3.NewCSHAKE128 and NewCSHAKE256 immediately de-reference this
result, this allocation is eliminated.
We eliminate the bytepad allocation by instead writing the various
values directly with SHAKE.Write. Values passed to Write don't escape
and, with the exception of data (which is initBlock), all our Writes are
of fixed size allocations. We can't simply modify bytepad to return a
fixed size byte-slice as the length of data is not constant nor does it
have a reasonable upper bound.
We're stuck with the initBlock allocation because of the API (Reset and
the various marshallers), but we still net a substantial improvement.
benchstat output using the following benchmark:
func BenchmarkSumCSHAKE256(b *testing.B) {
N := []byte("N")
S := []byte("S")
data := []byte("testdata")
b.SetBytes(64)
for b.Loop() {
SumCSHAKE256(N, S, data, 64)
}
}
name old time/op new time/op delta
SumCSHAKE256-12 1.09µs ±20% 0.79µs ± 1% -27.41% (p=0.000 n=10+9)
name old speed new speed delta
SumCSHAKE256-12 59.8MB/s ±18% 81.0MB/s ± 1% +35.33% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
SumCSHAKE256-12 536B ± 0% 88B ± 0% -83.58% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
SumCSHAKE256-12 4.00 ± 0% 2.00 ± 0% -50.00% (p=0.000 n=10+10)
Updates #69982
Change-Id: If426ea8127c58f5ef062cf74712ec70fd26a7372
Reviewed-on: https://go-review.googlesource.com/c/go/+/636255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
|
|
Fixes #75300
Change-Id: I6a83e0d040dba3366819d2afff704f886a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/723560
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Bypass: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
|
|
Check for invalid encodings and keys more systematically in
ParseRawPrivateKey/PrivateKey.Bytes,
ParseUncompressedPublicKey/PublicKey.Bytes, and
fips140/ecdsa.NewPrivateKey/NewPublicKey.
Also, use these functions throughout the codebase.
This should not change any observable behavior, because there were
multiple layers of checks and every path would hit at least one.
Change-Id: I6a6a46566c95de871a5a37996835a0e51495f1d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/724000
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
This commit integrates ML-DSA ACVP test coverage, describing the
capabilities of the crypto/internal/fips140/mldsa package and
adding the required command handlers to our ACVP module wrapper.
Change-Id: I2aee6f169752a6c6fec3a68591dde33e4f308081
Reviewed-on: https://go-review.googlesource.com/c/go/+/719703
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
|
|
fips140: off
goos: darwin
goarch: arm64
pkg: crypto/internal/fips140test
cpu: Apple M2
│ bade4ade59 │ bade4ade59-dirty │
│ sec/op │ sec/op vs base │
MLDSASign/ML-DSA-44-8 264.8µ ± 0% 244.5µ ± 0% -7.68% (p=0.000 n=20)
fips140: off
goos: linux
goarch: amd64
pkg: crypto/internal/fips140test
cpu: AMD EPYC 7443P 24-Core Processor
│ bade4ade59 │ bade4ade59-dirty │
│ sec/op │ sec/op vs base │
MLDSASign/ML-DSA-44-48 408.7µ ± 3% 386.5µ ± 1% -5.41% (p=0.000 n=20)
Change-Id: I04d38a48d5105cbcd625cba9398711b26a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/723020
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
This commit updates the BoringSSL module version used for the acvptool,
as well as the module version used for the static test data used by our
CI process to avoid interacting with a live ACVP server.
Two important upstream changes of note:
1. NIST changed the ML-KEM format slightly, and the BoringSSL acvptool
was updated in turn. We need to update the go-acvp data version to
one where I've regenerated the corresponding vector/expected files to
match these changes. Otherwise, we see an error from an empty dk
value.
2. The upstream BoringSSL acvptool switched to no longer truncating MAC
output in the subprocess handler for HMAC tests. Instead of relying on
this, we switch our capabilities to describe the output length we
return natively. In turn, we need to update the go-acvp data version
to vectors generated with the updated capabilities. Otherwise, we see
an error from the acvptool that our module wrapper returned a result
of the wrong length.
Change-Id: I1def172585ced0aaf1611d82f2e2802ca1500390
Reviewed-on: https://go-review.googlesource.com/c/go/+/719780
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
Change-Id: I6a6a6964fabee819e62bb6eda032dee6a60d907a
Reviewed-on: https://go-review.googlesource.com/c/go/+/717781
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
Updates #75300
Change-Id: I87ed26e8f57180d741408bdbda1696d46a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/719560
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
|
|
Updates #75300
Change-Id: I6a6a6964fbd45420b4001f53fa79228808e4778a
Reviewed-on: https://go-review.googlesource.com/c/go/+/705797
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Updates #75300
Change-Id: I6a6a6964de449b36bc6f5594e08c3c47a0a2f17f
Reviewed-on: https://go-review.googlesource.com/c/go/+/701435
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
We were mistakenly doing NTT⁻¹ inside the inner loop, on the components
of the inner product intead of the sum, leading to k² = 9 inverse NTT
calls instead of k = 3 inverse NTT.
Surprisingly large speedup as a result.
fips140: off
goos: darwin
goarch: arm64
pkg: crypto/mlkem
cpu: Apple M2
│ 4c285e0988 │ 4c285e0988-dirty │
│ sec/op │ sec/op vs base │
KeyGen-2 28.95µ ± 3% 28.64µ ± 4% ~ (p=0.699 n=6)
Encaps-2 43.13µ ± 3% 35.02µ ± 1% -18.81% (p=0.002 n=6)
Decaps-2 43.80µ ± 1% 35.49µ ± 1% -18.97% (p=0.002 n=6)
RoundTrip/Alice-2 77.27µ ± 7% 69.12µ ± 3% -10.55% (p=0.002 n=6)
RoundTrip/Bob-2 43.08µ ± 2% 35.14µ ± 3% -18.44% (p=0.002 n=6)
geomean 44.88µ 38.67µ -13.84%
Change-Id: I6a6a69649c1378411c9aca75d473fd5b9984a609
Reviewed-on: https://go-review.googlesource.com/c/go/+/715381
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
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>
|
|
Change-Id: I6a6a6964725fed48b55ce72a24a8f9bd3044ae16
Reviewed-on: https://go-review.googlesource.com/c/go/+/719940
Reviewed-by: Roland Shoemaker <roland@golang.org>
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: Junyang Shao <shaojunyang@google.com>
|
|
This change mechanically replaces all occurrences of interface{}
by 'any' (where deemed safe by the 'any' modernizer) throughout
std and cmd, minus their vendor trees.
Since this fix is relatively numerous, it gets its own CL.
Also, 'go generate go/types'.
Change-Id: I14a6b52856c3291c1d27935409bca8d5fd4242a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/719702
Commit-Queue: Alan Donovan <adonovan@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
|
|
Intrinsifying things inside the module (crypto/internal/fips140/subtle)
is asking for trouble, as the import paths are rewritten by the
GOFIPS140 mechanism, and we might have to support multiple modules
in the future.
Importing crypto/subtle from inside a FIPS 140-3 module is not allowed,
and is basically asking for circular dependencies.
Instead, break off the intrinsics into their own package
(crypto/internal/constanttime), and keep the byte slice operations
in crypto/internal/fips140/subtle. crypto/subtle then becomes a thin
dispatch layer.
Change-Id: I6a6a6964cd5cb5ad06e9d1679201447f5a811da4
Reviewed-on: https://go-review.googlesource.com/c/go/+/716120
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
|
|
Fixed two issues in AVO based generator of amd64 asm code.
1. Updated golang.org/x/tools dependency to prevent build issue in Go 1.25.
> golang.org/x/tools@v0.24.0/internal/tokeninternal/tokeninternal.go:64:9:
> invalid array length -delta * delta (constant -256 of type int64)
This error was caused by changes in layout of data structures in Go. Package
golang.org/x/tools has a mirror of that struct and a static assert that it
matches the Go's struct.
2. Changed the package name from crypto/aes to crypto/internal/fips140/aes.
This fixed run time error:
> ctr_amd64_asm.go:31: could not find function "ctrBlocks1Asm"
and other errors
Now the following works as expected:
$ cd src/crypto/internal/fips140/aes/_asm/ctr/
$ go generate
The command re-generates file "src/crypto/internal/fips140/aes/ctr_amd64.s".
Fixes #75972
Change-Id: I28e4c9ebb5bf72506a524e36a0c81a1b50367a84
GitHub-Last-Rev: afc9f506e50df6dc25fd285d5a597b0e5c93b5d9
GitHub-Pull-Request: golang/go#75973
Reviewed-on: https://go-review.googlesource.com/c/go/+/712920
Reviewed-by: David Chase <drchase@google.com>
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>
|
|
Change-Id: I6a6a6964642991dc46929bfc47e411bb7563e425
Reviewed-on: https://go-review.googlesource.com/c/go/+/716080
Auto-Submit: Filippo Valsorda <filippo@golang.org>
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>
|
|
Change-Id: I6a6a69649df8f576df62e22c16db7813cde75224
Reviewed-on: https://go-review.googlesource.com/c/go/+/715401
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
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>
|
|
The crypto/internal/fips140/entropy package vendors a minimal
implementation of SHA2-384 to insulate it from changes in the FIPS
module implementation. This means it also requires ACVP testing separate
from the FIPS module implementation. This commit implements the
required ACVP testing support.
There's no way via the ACVP protocol, or acvptool, to specify that we
want to test a specific SHA2-384 implementation compared to normal. We
use a new environment variable (GOENTROPYSOURCEACVP=1) to make that
distinction.
The capabilities we advertise when testing the entropy SHA2-384
implementation are limited to something that best describes the
input sizes that the entropy module's implementation supports within the
requirements imposed by ACVP. We allow 144 byte messages (3*digest size)
to support MCT and in particular the "standard" MCT algorithm, and allow
1024 byte messages as the production supported message size used by the
entropy module itself.
Change-Id: I6e693a3fa23efba35d8a7d029ddf0b11036621c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/711740
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: 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>
|
|
TestNISTECAllocations is flaky (~1% failure rate) on my local Windows
machine since CL 710058, which touched TestEntropyRace.
These tests are unrelated, but some allocations might be incorrectly
accounted to TestNISTECAllocations, affecting the end result due to
the low number of iterations done in that test.
Change-Id: I01323c2a45b12665e86d940467f4f91c2e66696b
Reviewed-on: https://go-review.googlesource.com/c/go/+/712620
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The lab confirmed the that entropy source doesn't have to be inside the
module boundary, although changing the entropy source of a module does
require recertification.
Move the v1.0.0 entropy source out of crypto/internal/fips140, to a
versioned path that lets us keep multiple versions (which would be used
by different modules) if we wish to.
Change-Id: I6a6a69647e9dfca1c375650a0869bdc001d65173
Reviewed-on: https://go-review.googlesource.com/c/go/+/710057
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
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: Dmitri Shuralyov <dmitshur@google.com>
|
|
Change-Id: I390c380349e99ad421264b673ad7734eddb639d3
GitHub-Last-Rev: 32e849a6420574b0d878b9a449a8c044fd6ebdd1
GitHub-Pull-Request: golang/go#75905
Reviewed-on: https://go-review.googlesource.com/c/go/+/711941
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Fixes #75690
Fixes #75842
Change-Id: I6a6a696420f51f28f48535c34cf347e2cbd4add5
Reviewed-on: https://go-review.googlesource.com/c/go/+/710058
Auto-Submit: Filippo Valsorda <filippo@golang.org>
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>
|
|
Change-Id: I6a6a6964decc662d753ee3eec357570bd3c95e2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/710056
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: Nooras Saba <noorassaba@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
|
|
Change-Id: I6a6a69642d00e3994277d9b5631d1d7f18f3f356
Reviewed-on: https://go-review.googlesource.com/c/go/+/710055
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>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
xorBytes for mips64x"
This reverts commit 49d6777d87a0abb3eda032da95eff024156835f7.
Reason for revert: doesn't handle unaligned accesses correctly
Fixes #74998
Change-Id: Ia272245a6a2a91b305d411207430bad660ee355b
Reviewed-on: https://go-review.googlesource.com/c/go/+/709757
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|