Repository navigation
feat: add AES-256-CTR-HMAC-SHA512 cipher suites from draft-barnes-sframe-iana-256 - #98
Merged
pabuhler merged 1 commit intoSep 23, 2026
Conversation
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
No unresolved review issues remain, and the supplied readiness assessments support approval.
Review effort: Lite
Findings: None
What changed in this PR
Adds three AES-256-CTR-HMAC-SHA512 SFrame cipher suites (IDs 6–8) with backend support, expanded key sizing, tests, and fuzz coverage.
Changes:
- Registers suite parameters and AES-256/SHA-512 implementations.
- Expands key and HKDF buffers for 96-byte derived keys.
- Adds official vectors, round-trip tests, and fuzz-suite coverage.
| File | Description |
|---|---|
test/test-vectors.json |
Adds official AES-256 known-answer vectors. |
test/sframe.cpp |
Adds round-trip coverage for the new suites. |
src/sframe.cpp |
Adapts MLS key derivation sizing. |
src/crypto.h |
Expands HKDF output capacity. |
src/crypto.cpp |
Registers suite parameters. |
src/crypto_openssl3.cpp |
Adds OpenSSL 3 AES-256/SHA-512 support. |
src/crypto_openssl11.cpp |
Adds OpenSSL 1.1 AES-256/SHA-512 support. |
src/crypto_boringssl.cpp |
Adds BoringSSL AES-256/SHA-512 support. |
include/sframe/sframe.h |
Adds suite identifiers and increases key capacity. |
fuzz/fuzz_unprotect.cpp |
Includes all eight suite IDs in fuzzing. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
k-wasniowski
force-pushed
the
feat-support-draft-barness-extra-cipher-suites
branch
from
September 23, 2026 07:03
9e19f76 to
20ba966
Compare
k-wasniowski
force-pushed
the
feat-support-draft-barness-extra-cipher-suites
branch
from
September 23, 2026 07:12
20ba966 to
87ce14f
Compare
k-wasniowski
force-pushed
the
feat-support-draft-barness-extra-cipher-suites
branch
from
September 23, 2026 07:27
87ce14f to
630c278
Compare
k-wasniowski
marked this pull request as ready for review
September 23, 2026 09:12
pabuhler
approved these changes
Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add AES-256-CTR-HMAC-SHA512 cipher suites
Summary
Implements the three cipher suites registered in draft-barnes-sframe-iana-256, which extend the SFrame CTR+HMAC compound AEAD construction (Section 4.5.1 of RFC 9605) to the 256-bit security level:
AES_256_CTR_HMAC_SHA512_80AES_256_CTR_HMAC_SHA512_64AES_256_CTR_HMAC_SHA512_32Motivation
The CTR+HMAC construction was only defined for AES-128 / HMAC-SHA256. Deployments that require a 256-bit security level but cannot use AES-GCM (e.g. because they need short authentication tags) had no usable suite. The construction itself is unchanged apart from field lengths, so this is a small, mechanical extension.
Changes
Public API
include/sframe/sframe.h: addedAES_256_CTR_HMAC_SHA512_80/_64/_32toCipherSuite.KeyRecord::max_key_sizeraised from 48 to 96 bytes to hold a 32-byte AES-256 key plus a 64-byte HMAC-SHA512 key. This is a build-time size constant, so pre-built binaries must be rebuilt in lockstep with consumers (as already documented forSFRAME_MAX_KEYS/SFRAME_EPOCH_BITS).Cipher suite parameters
src/crypto.cpp: registeredNh,Nka,Nk,NnandNtfor the new suites incipher_digest_size,cipher_key_size,cipher_enc_key_size,cipher_nonce_sizeandcipher_overhead.Crypto backends
All three backends map the new suites to AES-256-CTR + SHA-512 and route
seal/openthrough the existing CTR+HMAC path:src/crypto_openssl3.cpp(EVP_aes_256_ctr(),OSSL_DIGEST_NAME_SHA2_512)src/crypto_openssl11.cpp(EVP_aes_256_ctr(),EVP_sha512())src/crypto_boringssl.cpp(EVP_aes_256_ctr(),EVP_sha512())HKDF buffer sizing
src/crypto.h:max_hkdf_expand_sizeraised from 64 to 96 soderive_key_saltcan produce the 96-byte key.max_hkdf_extract_sizestays at 64 (the largest hash output).max_hkdf_extract_size/max_hkdf_expand_sizereturn types swapped relative to the declarations incrypto.h. This was harmless while both constants were 64, but became a compile error once they diverged, so the definitions now match the declarations.src/crypto_openssl11.cpp: the size guard inhkdf_expandnow bounds againstmax_hkdf_expand_size. The surrounding loop already iterates over HKDF blocks, so deriving 96 bytes from SHA-512 (two blocks) works without further change.src/sframe.cpp:MLSContext::EpochKeys::base_keynarrows thehkdf_expandresult to the 64-byte epoch secret buffer explicitly; the derived value is still hash-sized, so no truncation occurs.Testing
test/test-vectors.json: added the three official SFrame known-answer vectors from the draft (test-vectors-aes256.json), verified verbatim by the existingSFrame Test Vectorscase.test/sframe.cpp: the new suites are exercised bySFrame Round-Trip,MLS Round-TripandMLS Round-Trip with context.fuzz/fuzz_unprotect.cpp: the suite selector now spans all 8 registered code points.All 13 tests pass against system OpenSSL 3 with
-DTESTING=ON -DCMAKE_BUILD_TYPE=Debug, with no new compiler warnings.Compatibility
KeyRecordgrows by 48 bytes, which increases the footprint ofContext::keysinNO_ALLOCbuilds (SFRAME_MAX_KEYSentries).