[alex]

Part of #1228. This PR only adds benchmarks. It changes no library code.

Why

Every AES-GCM benchmark sets up a new key for each message. On x86-64 with AVX-512 and VAES, a key switches to the _prepared functions once it has been used for 32 messages of at least 256 bytes (POWERS_AFTER). Those functions read precomputed powers of the hash subkey. They are what a TLS or QUIC connection's key uses (see the rustls analysis in #991), yet no benchmark reaches them today. Changes to them, such as #1404, therefore show nothing in the Benchmarks check.

What

Two new groups, measured at REUSED_SIZES = 600, 1350 and 4000 bytes. These sizes leave 5, 4 and 10 blocks after the last group of 16, and are above the 32-block short path:

• aes-128-gcm-encrypt-reused-key: encrypt_in_place.
• aes-128-gcm-encrypt-two-pieces-reused-key: encrypt from a TLS 1.3 record's payload and its content-type byte.

Each runs next to OpenSSL (one CipherCtx keyed once and given a new nonce per message) and aws-lc-rs (one LessSafeKey). Before the timings, the outputs and tags are checked against OpenSSL's.

Results on main

Measured on a VAES/AVX-512 machine (criterion medians):

group	bytes	verified-garbage	OpenSSL	aws-lc-rs
in place	600	211 ns	297 ns	162 ns
in place	1350	251 ns	345 ns	196 ns
in place	4000	420 ns	534 ns	361 ns
two pieces	600	189 ns	334 ns	165 ns
two pieces	1350	228 ns	356 ns	205 ns
two pieces	4000	423 ns	548 ns	374 ns

cargo fmt --check, cargo clippy --all-targets -D warnings (in bench/) and ci/check_arch_gates.py pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FoYWDDEDFq1DFev5X7n2aq

---

Generated by Claude Code