This issue was discovered during CI testing on LUCI, specifically in the gotip-linux-amd64-boringcrypto and gotip-linux-arm64-boringcrypto environments. The exact Go version is the latest development version ('gotip') as of the date of this report.
Output of go env in your module/workspace:
The exact go env output is not available as this issue was discovered in LUCI's CI environment. However, the relevant information is that this affects Linux environments on amd64 and arm64 architectures with BoringCrypto enabled.
What did you do?
This issue arose in a CL to add tests for the cipher.Stream interface in the crypto library.
LUCI ran checks on patchset 1 (commit 32df86a3b577af116eee37fa58964acc6ca3234b) to yield errors found by the Stream tester: "Test crypto/cipher.TestCTRStream/WrongIVLen failed."
The CL runs a test to check that creating a new CTR blockmode stream with NewCTR panics when given an IV with length different from block size, but it does not panic for the above architectures with BoringCrypto enabled.
Rather than considering patchset 1 of the above CL, here is a minimal reproduction of the issue. In the actual environment, this test passes on some architectures but fails on Linux amd64 and arm64 with BoringCrypto enabled. You can run this code in the Go playground to see the expected behavior (where the test passes). In a failing environment, this test unexpectedly fails.
What did you see happen?
For gotip-linux-amd64-boringcrypto check:
builder: gotip-linux-amd64-boringcrypto-test_only, go_branch: master, goarch: amd64, goos: linux, host_goarch: amd64, host_goos: linux
Run #1: unexpectedly failed
=== RUN TestCTRStream/WrongIVLen
stream.go:239: Deterministic RNG seed: 0x17ddcd094d6111a0
stream.go:199: function did not panic, wanted "IV length must equal block size"
--- FAIL: TestCTRStream/WrongIVLen (0.00s)
For gotip-linux-arm64-boringcrypto check:
builder: gotip-linux-arm64-boringcrypto-test_only, go_branch: master, goarch: arm64, goos: linux, host_goarch: arm64, host_goos: linux
Run #1: unexpectedly failed
=== RUN TestCTRStream/WrongIVLen
stream.go:239: Deterministic RNG seed: 0x17ddccdcaeac5eb0
stream.go:199: function did not panic, wanted "IV length must equal block size"
--- FAIL: TestCTRStream/WrongIVLen (0.00s)
What did you expect to see?
The expected behavior is that this test passes because NewCTR will panic on this test as expected.
NewCTR is defined here in the crypto/cipher package and seems to conditionally decide how to construct the new CTR blockmode in a way that will use the "boring" implementation when enabled for the correct architecture.
For amd64 and arm64 with BoringCrypto enabled, this version of NewCTR may be called and might be the problematic implementation that does not panic when given IV not of length block size.
Go version
This issue was discovered during CI testing on LUCI, specifically in the gotip-linux-amd64-boringcrypto and gotip-linux-arm64-boringcrypto environments. The exact Go version is the latest development version ('gotip') as of the date of this report.
Output of
go env
in your module/workspace:The exact
go env
output is not available as this issue was discovered in LUCI's CI environment. However, the relevant information is that this affects Linux environments on amd64 and arm64 architectures with BoringCrypto enabled.What did you do?
This issue arose in a CL to add tests for the cipher.Stream interface in the crypto library. LUCI ran checks on patchset 1 (commit 32df86a3b577af116eee37fa58964acc6ca3234b) to yield errors found by the Stream tester: "Test crypto/cipher.TestCTRStream/WrongIVLen failed."
Specifically, this occurs on check gotip-linux-amd64-boringcrypto and on gotip-linux-arm64-boringcrypto.
The CL runs a test to check that creating a new CTR blockmode stream with NewCTR panics when given an IV with length different from block size, but it does not panic for the above architectures with BoringCrypto enabled.
Rather than considering patchset 1 of the above CL, here is a minimal reproduction of the issue. In the actual environment, this test passes on some architectures but fails on Linux amd64 and arm64 with BoringCrypto enabled. You can run this code in the Go playground to see the expected behavior (where the test passes). In a failing environment, this test unexpectedly fails.
What did you see happen?
For gotip-linux-amd64-boringcrypto check:
For gotip-linux-arm64-boringcrypto check:
What did you expect to see?
The expected behavior is that this test passes because NewCTR will panic on this test as expected.
NewCTR is defined here in the crypto/cipher package and seems to conditionally decide how to construct the new CTR blockmode in a way that will use the "boring" implementation when enabled for the correct architecture. For amd64 and arm64 with BoringCrypto enabled, this version of NewCTR may be called and might be the problematic implementation that does not panic when given IV not of length block size.