Repository navigation
Conversation
…ld carry its own key type to prevent using keys across algorithms. This ended up being harder than it looked and ended up adding a new public trait SymmetricCipherKey\<KEY_LEN\> which is a shallow wrapper for a KeyMaterial\<KEY_LEN\>, and then carrying a generic param 'K: SymmetricCipherKey\<KEY_LEN\>' all the way down the stack of stuff in the bouncycastle-cipher crate. Touched a ton of files, but everything works now, and I think it's prettier than the old system with bare KeyMaterials. Heavily assisted-by: Claude Fable 5.1
Contributor
Author
|
Marking as Draft because I want to review it carefully myself first. |
1 of 4 tasks
officialfrancismendoza
added a commit
that referenced
this pull request
Oct 22, 2026
Keeping a key to one algorithm is moving to compile-time key types (#167), so the opt-in runtime binding that 0de70ae added goes. Nothing outside the tests ever bound a key, so no cipher call outside them changes outcome; KeyMaterial's Display/Debug lose the `algorithm` field. Removed: - KeyMaterial's `algorithm` field and KeyMaterialTrait::algorithm, set_algorithm and check_algorithm. - The 26 check_algorithm calls: 24 in crypto/cipher, one in Ascon's checked_key, one in the ToyCbc test double. The cipher imports go back to KeyMaterial alone. - The framework's key_binding module and its four suite blocks, two tests in key_material_tests.rs, and aes/tests/key_binding_tests.rs, including the cross-size test 6994217 added there. This is not `git revert 0de70ae`: that commit also folded the two ToyBlockCipher copies into the cipher crate's, which stays, and a plain revert conflicts with 6994217. Files no later commit touched are back to 0de70ae~1 byte for byte. #172's from_key_material and #157's ChaCha20 keys still call check_algorithm, and need the same removal when they next merge this. cargo test --workspace --no-fail-fast: 1106 passed, 1 failed. The failure is ascon_wycheproof, whose vector file is missing from the local wycheproof checkout; it fails the same way without this change. Assisted-by: Claude:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dghgit
added a commit
that referenced
this pull request
Oct 25, 2026
…type) Lifted from #167, whose SymmetricCipherKey bound every key on PartialEq + Eq: a caller that holds two keys can ask whether they are the same key without reaching the material, which the key objects never hand back. Equality is over the expanded state and decided in constant time at every layer. AESInternal compares its schedule through Secret's byte-wise equality, which inspects every byte (round key 0 is the key itself, so two schedules are equal exactly when the keys are); GcmKeyState and CmacKeyState compare the permutation and their derived values joined with `&` rather than `&&`, so the time taken does not say which field differed; AESKey<P, M> is equal when its mode state is, bounded on the state rather than on Mode::KeyState so that a permutation without the impl still has keys; AsconAEAD128Key compares its Secret words. Mode::KeyState's docs now say that a state implementing PartialEq must compare in constant time. Tests: equality follows the material, for a clone, the same bytes and a single differing byte, through the bare schedule (CTR), GCM at 128 and 256 bits, CMAC and Ascon. Assisted-by: Claude:claude-mythos-5-1
1 of 4 tasks
ounsworth
changed the base branch from
feature/simple-ciphers
to
release/0.1.3alpha
October 25, 2026 16:32
ounsworth
changed the base branch from
release/0.1.3alpha
to
feature/simple-ciphers
October 25, 2026 16:33
Contributor
Author
|
Closing as this has been replaced by #181 |
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.
Each symmetric cipher instantiation (AES_GCM_128, Ascon_AEAD128) should carry its own key type to prevent using keys across algorithms. This ended up being harder than it looked and ended up adding a new public trait SymmetricCipherKey<KEY_LEN> which is a shallow wrapper for a KeyMaterial<KEY_LEN>, and then carrying a generic param 'K: SymmetricCipherKey<KEY_LEN>' all the way down the stack of stuff in the bouncycastle-cipher crate. Touched a ton of files, but everything works now, and I think it's prettier than the old system with bare KeyMaterials. Heavily assisted-by: Claude Fable 5.1