crypto/internal/boring: NewCTR does not panic when given an IV with different length than block size

[msabin]

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:

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.

[msabin]

As requested @FiloSottile @rolandshoemaker

[gabyhelp]

Related Issues and Documentation

• x/crypto/wycheproof: TestHkdf cgo errors with boringcrypto #54557 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cagedmantis]

cc @golang/security