test(aead): Sample fragment sizes in AEAD record tests

[alexw91]

Goal

Reduce the runtime of the two slowest s2n-tls unit tests, s2n_aead_aes_test and s2n_aead_chacha20_poly1305_test.

Why

See: #5704

These two tests dominated local unit test iteration time on developer machines:

• s2n_aead_aes_test: 232.37 sec
• s2n_aead_chacha20_poly1305_test: 121.70 sec

Both tests iterated over every fragment size from 0 to S2N_SMALL_FRAGMENT_LENGTH + 1 (1437 iterations), and for each size ran inner tamper-detection loops that scaled linearly with the payload size. This quadratic structure made them the longest-running unit tests in the suite without providing meaningfully better coverage than sampling representative sizes would.

Before this change:

278/279 Test   #3: s2n_aead_chacha20_poly1305_test ..................   Passed  121.70 sec
279/279 Test   #2: s2n_aead_aes_test ................................   Passed  232.37 sec

After this change:

256/279 Test   #3: s2n_aead_chacha20_poly1305_test ..................   Passed    3.28 sec
264/279 Test   #2: s2n_aead_aes_test ................................   Passed    5.10 sec

Runtime comparison:

Test	Before	After	Speedup
s2n_aead_aes_test	232.37 sec	5.10 sec	~45x
s2n_aead_chacha20_poly1305_test	121.70 sec	3.28 sec	~37x

How

Replace the exhaustive for (size_t i = 0; i <= max_fragment + 1; i++) outer loop in both test files with iteration over a fixed set of 33 fragment sizes chosen to cover the boundaries that actually matter:

• All sizes 0-8 (small-payload edge cases)
• Values around each power of two through 1024 (n-1, n, n+1 for 16, 32, 64, 128, 256, 512, 1024)
• The fragment length limit boundary (max-1, max, max+1)

The inner tamper-detection and validation logic is unchanged. The AES test still covers both AES128-GCM and AES256-GCM; the ChaCha20-Poly1305 test is unchanged in scope.

Callouts

• This is a coverage trade-off. An AEAD construction does not have "weak byte positions" or "weak payload sizes" that require exhaustive enumeration to catch, once tamper detection is verified at representative sizes, additional sizes provide diminishing returns.
• The inner payload-tamper loops (for (j = 0; j < i; j++)) are still O(N) per outer iteration. That's why the max-fragment case (size 1435) still dominates the remaining runtime.

Testing

Ran unit tests locally on an M4 MacBook Pro. Both tests pass, and all other unit tests continue to pass.

Related

• Reduce runtime of slowest unit tests #5704

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.