Simple ciphers: stream + symmetric cipher unification off the release branch, plus SHA-512/t for any t by dghgit · Pull Request #133 · bcgit/bc-rust

dghgit · 2026-09-16T04:56:40Z

Consolidates the stacked pair #113 (feature/stream-cipher → release/0.1.3alpha) and #115
(feature/symmetric-cipher → feature/stream-cipher) into a single branch off the release
branch, and adds the SHA-512/t work on top.

feature/simple-ciphers was built by branching from release/0.1.3alpha and merging
feature/stream-cipher then feature/symmetric-cipher; both merges fast-forwarded, so the
content below the two new commits is exactly what #113 and #115 already carried — this is a
re-packaging, not new review surface. #113 (+21,938) and #115 (+2,310) sum to roughly the
+23,499 here.

New in this PR, on top of those two

core: SecurityStrength::from_bits / from_bytes become const fn (3912434) — two
keywords, no behaviour change. Needed so an associated const can derive a strength from a const
generic; split out ahead of the feature per CLAUDE.md's scope-of-changes rule.

sha2: SHA512t<T> is usable for every t FIPS 180-4 s. 5.3.6 defines a hash for (785dbef).
Previously only T = 224 and T = 256 had parameter impls, so nothing else could be named.

The t-value checks are back, and they are the spec's. b11f8f6 had narrowed sha512t_h0 to
100 <= t < 512 and emitted a fixed three digits, since only 224 and 256 were reachable. With
arbitrary t reachable that would produce the "0256" spelling s. 5.3.6 explicitly forbids —
and hence the wrong IV — for every t below 100. The one- and two-digit branches are restored
and check_t asserts the section's own rule: positive, < 512, not 384.
One deviation, documented: t must be a multiple of 8, because Hash is byte-oriented and
a 100-bit digest has no representation here. BC Java's SHA512tDigest imposes the identical
restriction, so the two libraries accept the same set of truncations.
Unapproved truncations are gated the way ElectronicCodeBook::ENCRYPTION_APPROVED gates
two-key TDEA: SHA512tParams::<T>::FIPS_APPROVED is public and SHA512Internal::new asserts it
in an inline const, so an unapproved t is a compile error at the call site and
new_allow_unapproved_t() is the deliberate way in. That also blocks Default, which keeps an
unapproved truncation out of generic code by accident.
ALG_NAME, OUTPUT_LEN and MAX_SECURITY_STRENGTH are derived from t, with const
assertions pinning them to the values 224 and 256 previously had by hand.

Verification

cargo test --workspace: 943 passed, 0 failed (was 923). cargo fmt --check clean; no new
clippy warnings. Both new commits build independently.
Spec text read from a freshly downloaded FIPS 180-4, not from recall.
Test vectors cross-checked against BC Java's SHA512tDigest, an independent implementation:
eight truncations (8, 16, 24, 88, 96, 104, 264, 504) spanning all three decimal branches, over
the FIPS 180-4 Appendix C messages plus the one-million-'a' case. The 224/256 rows in the same
table match the NIST-published values.
cargo mutants on the changed files: 259 mutants — 180 caught, 5 timeout-kills, 69 unviable,
5 missed. All five missed are the pre-existing XOR/OR equivalences already annotated at their
sites in ch, maj and do_final_internal; no new missed mutants.

Note for reviewers

Adding const to a public core function is a forward compatibility commitment, and
SHA512tParams is currently its only caller. The alternative was a private copy of the rounding
ladder inside sha2, free to drift from the real one — happy to switch if the API-surface cost is
the greater worry.

🤖 Generated with Claude Code

…into feature/stream-cipher

…ems like a personal workflow rather than a general thing.

…Added a note about this to QUALITY_AND_STYLE.md.

…so the lib target the src/ move introduced does not compile them as failing Rust doctests

…ding, and the SHA-512/t sealing trait is now named SHA512InitValue

….6 prints it, with H(0)'' on the left of the XOR and as the IV of the final SHA-512 call

…enches sources moved under src/ and are now doctested, and integration tests are preferred per QUALITY_AND_STYLE.md

…, dropping the one- and two-digit branches of s. 5.3.6 that no approved-t caller or test could reach; of its 43 mutants none is now missed

…th other crates

…4 a comment claimed, and exceeding it truncates the 64-bit length field silently instead of panicking on the byte-count add, so do_update asserts it in debug builds; sha512t_h0's assertion stops crediting FIPS 180-4 s. 5.3.6 with the t >= 100 its own three-digit formatting imposes, and a new test pins the 128-bit length carry that exempts SHA-512

… l < 2^64 bits, and exceeding it truncates the 64-bit length field silently instead of panicking on the byte-count add, so do_update asserts it in debug builds

…tor bundled into a feature commit makes the diff unreviewable however correct it is, so a refactor that unblocks the task goes in its own commit ahead of it and one that unblocks nothing gets proposed rather than done

… whose per-hash instantiations live in the hash crates, so HMAC_SHA512_224 and HMAC_SHA512_256 move to sha2::hmac as HMACParams impls; HMAC-SM3 is dropped here and reinstated under the new layout in the following commit, which is the only way to keep both commits building

…ed, as a new sm3::hmac module holding the HMACParams impl, the HMAC_SM3 alias and the OSCCA OID, with its criterion bench, factory and CLI wiring and known-answer tests restored alongside it

…anch, taking the shortened release notes from b282942 over the long form this branch still carried and accepting 5825050's deletion of core-test-framework/summary.md; no code conflicts, since the MAC factory and CLI changes are additive here

…a parameter set can derive MAX_SECURITY_STRENGTH from a const generic instead of naming a variant by hand; no behaviour change, and the following commit is the first caller that needs it Assisted-by: Claude:claude-opus-5 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…a hash for, not just the two approved truncations, so the IV Generation Function regains the one- and two-digit decimal branches that b11f8f6 dropped as unreachable -- writing a fixed three digits gives the "0256" spelling the section forbids, and hence the wrong IV, for every t below 100; t is checked against the section's own rule (positive, below 512, not 384) plus this crate's multiple-of-8 requirement, which BC Java's SHA512tDigest also imposes, and the unapproved truncations carry SHA512tParams::FIPS_APPROVED = false which SHA512Internal::new asserts in an inline const, so reaching one takes new_allow_unapproved_t() the way an encrypting mode takes ENCRYPTION_APPROVED; ALG_NAME, OUTPUT_LEN and MAX_SECURITY_STRENGTH are now derived from t and pinned to their old values for t = 224 and t = 256; new sha512t_tests.rs cross-checks eight truncations spanning all three digit branches against BC Java, and of the file's 259 mutants 180 are caught, 5 die on timeout and the 5 missed are the XOR/OR equivalences already documented at their sites Assisted-by: Claude:claude-opus-5 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ueezing becomes its own type

…utants survived

…oFinal after doOutput

… encodings and cshake CLI subcommands

…tions and the commit message style in CLAUDE.md

…Dir> is a plain alias The two wrapper structs fold into the cipher type: the AEAD and symmetric-cipher trait impls, the in-place pair and `SuspendableKeyed` are written on `AsconAEAD128<Encrypting>` / `AsconAEAD128<Decrypting>` directly, and `Ascon_AEAD128<Dir>` aliases it the way `AES_GCM_128<Dir>` aliases `Gcm`, rather than projecting through `Direction::Select`. The private core methods take names that do not collide with the trait methods (`absorb_aad`, `encrypt_bytes`, `finish_tag`, `decrypt_bytes`, `verify_tag`). The decrypting side's held-back bytes live in the struct for both directions, unused when encrypting, so both are 96 bytes in memory; the suspended layouts and their two length constants are unchanged. Assisted-by: Claude:claude-mythos-5-1

The cipher type takes the spec spelling directly, `Ascon_AEAD128<Dir>`, in place of `AsconAEAD128<Dir>` plus an alias to it; the alias's usage example moves onto the struct. Assisted-by: Claude:claude-mythos-5-1

Assisted-by: Claude:claude-mythos-5-1

The CCM packet decryptor's streaming method transforms its buffer in place, which is what the stream-cipher traits and Ascon call `do_*_inplace`; `do_decrypt_update` read as the out-of-place form the AEAD traits provide. Two labels that named a `do_encrypt_update` which never existed now name `do_encrypt`. Assisted-by: Claude:claude-mythos-5-1

Assisted-by: Claude:claude-mythos-5-1

…, as required by the library fn contracts.

ounsworth · 2026-10-21T21:14:33Z

@@ -1,3 +1,11 @@
+mod aes_cbc_cmd;
+mod aes_ccm_cmd;


I have played with a few of the new CLIs:

aes128-cbc

aes128-gcm

aes256-gcm

ascon-aead128

ascon-hash256

ascon-xof128

I made a few adjustments, such as, we used to be exposing only CBC, which means that if you just tried to encrypt a file, then 15/16 of the time you would get an error about the input not being a multiple of 16 bytes. So I changed this so that the aes_cbc CLI options are CBC so that it just works and does something sane instead of leading to user frustration, or worse, encouraging users to invent their own broken / vulnerable padding schemes.

@dghgit , @officialfrancismendoza I'm less familiar with some of the more esoteric modes here -- like CCM and CFB8 -- can you guys build the cli and play with the new CLIs you're adding to make sure you're happy with the ergonomics? It's possible that some of these we should just remove from the CLI because they are too complicated / special-purpose to be worth exposing over the CLI.

…zmat::AESInternal

…tructions for what to do for a permutation that does not impl all modes

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>

…since that's its only consumer

ounsworth · 2026-10-22T16:07:58Z

+/// behaviour -- returning 1 rather than 0 for the data length -- are caught.
+pub fn stream_do_final() -> Result<([u8; 0], usize), SymmetricCipherError> {
+    Ok(([], 0))
+}


This is extremely bizzare.

It's not even attached to an object, so it's not even finishing the object. This is literally a public function that takes no parameters and does nothing.

What's the point of this?

ounsworth · 2026-10-22T16:08:38Z

+    out.copy_from_slice(input);
+    in_place(out)?;
+    Ok(input.len())
+}


Why is this a standalone static function and not part of a stream trait or the StreamCipher struct?

Taking the in_place function to call as a parameter seems like an overly-complicated pattern. What problem are you trying to solve with this construction instead of impl'ing do_update and do_final as part of a trait like we do everywhere else?

Also, this function won't work in a no_std env because it requires a .copy_from_slice on an array of indefinite length.

This seems like a worse version of the StreatCipherEncryptor / Decryptor that we already impl below. I suggest just deleting this. Unless there's a really compelling reason to keep it?

ounsworth · 2026-10-22T16:26:39Z

@@ -28,16 +28,24 @@

 use crate::{AlgorithmFactory, FactoryError};


Please add factories for all the new algorithms. I think we need:

aead_factory.rs

block_cipher_factory.rs

stream_cipher_factory.rs

symmetric_cipher_factory.rs

ounsworth · 2026-10-22T16:36:55Z

@@ -54,6 +54,69 @@ mod hash_factory_tests {
            let sha2 = HashFactory::new(sha2::SHA512_NAME).unwrap();
            assert_eq!(sha2.output_len(), 64);
            assert_eq!(sha2.hash(&DUMMY_SEED[..512]), b"\xed\xb9\xbe\xd7\x21\xaa\x6a\x5f\x6f\xbc\x66\x19\xd3\xa3\xc2\xbe\x3d\x04\x30\x43\xf0\x5a\x9a\xeb\xc7\xb1\x19\x7a\x2a\xa9\xc4\x9a\x57\xd5\xdd\xd4\x67\x4c\x17\x85\x78\x50\x88\xd9\xf1\xff\x42\xc7\x97\xa0\x2a\xdc\x9b\x81\x7a\x13\x9a\x50\x97\x0d\xa6\xc9\x95\x24");
+


Personally, I feel like we could just delete all of the factory test files.

Does the factory crate need tests? If so, what is meaningful to test? I suppose we could test that the factory wirings have exposed the right algorithm under the right name, but I think we could just do that against the ALG_NAME string; running KATs seems like overkill? (and is also hard to audit by eye that we're running the right KATs).

Is there a strong reason why I shouldn't delete the entire factory/tests dir?
Like, have you put any tests here that you think are valuable and should we should keep?

Right now I think I'd even delete the factories! We'll need something like them for dealing with CMP/CRMF/CMS, but what shape they'll take in a Rust environment currently eludes me.

That said, with testing, we just need enough to confirm that the factory provides a service which can be validated somehow against the service name used.

ounsworth · 2026-10-22T16:56:26Z

+        "cxof128_output" => bench_cxof128_output(),
+        "cxof128_oneshot" => bench_cxof128_oneshot(),
+        _ => print_struct_sizes(),
+    }


Please make this match the main() style of the other mem benches ... ie the style where all-but-one function is commented out, rather than this pattern of reading it off the command-line.

That pattern was intentional so that we're not measuring stack memory usage of the code that has to handle reading std::env and the switch.

ounsworth · 2026-10-22T16:58:59Z

+        "oneshot" => bench_oneshot_encrypt_out_detached(),
+        "direct_stream" => bench_direct_streaming(),
+        _ => print_struct_sizes(),
+    }


Ditto the comment in bench_ascon_mem_usage.rs; please make this match the style of the existing files.

…cipher traits in favour of the _blocks_inplace ones (since the former were shallow wrappers around the second with a worse public API). Also added a new SymmetricCipherError::DataNotBlockAligned to handle runtime checks for misalignments. Assisted-by: Claude Opus 5.5

ounsworth and others added 30 commits September 9, 2026 11:21

Merge branch 'feature/stream-cipher' of git.bouncycastle.org:bc-rust …

fc2fcb7

…into feature/stream-cipher

Restructured the mem_usage_benchmarks sub-crate

d66cd0b

Reverting the SKILL.md changes about producing a report since this se…

dc248f9

…ems like a personal workflow rather than a general thing.

Moves sha512t_h0 tests out of unit tests and into integration tests. …

7539532

…Added a note about this to QUALITY_AND_STYLE.md.

rename sha2/tests/cavc_tests.rs to bc-test-data.rs to match other crates

b0bd491

Renaming / readability of some of the SHA2 internal traits.

097c09b

mem_usage_benches: fence the valgrind and ms_print snippets as text, …

55f53f7

…so the lib target the src/ move introduced does not compile them as failing Rust doctests

sha2: the partial-byte example's three bits are message bits, not pad…

0156990

…ding, and the SHA-512/t sealing trait is now named SHA512InitValue

sha2: quote the SHA-512/t IV Generation Function as FIPS 180-4 s. 5.3…

213473c

….6 prints it, with H(0)'' on the left of the XOR and as the IV of the final SHA-512 call

CLAUDE.md: the build and test gates need --workspace, the mem_usage_b…

5fc1370

…enches sources moved under src/ and are now doctested, and integration tests are preferred per QUALITY_AND_STYLE.md

sha2: sha512t_h0 asserts three-digit t and formats it as three digits…

b11f8f6

…, dropping the one- and two-digit branches of s. 5.3.6 that no approved-t caller or test could reach; of its 43 mutants none is now missed

Removing summary.md files

5825050

minor tweaks to sha2

0cc2799

Gave a massive hair-cut to Claude's massive release note

b282942

Rename sha3/tasts/cavp_tests.rs to bc-test-data.rs for consistency wi…

8b48d93

…th other crates

small tweaks to sm3

6cc74c2

doc change to the mem bench scripts

0558f26

sm3: the message limit is 2^61 bytes, GB/T 32905-2016 s. 5.1 allowing…

cb0429c

… l < 2^64 bits, and exceeding it truncates the 64-bit length field silently instead of panicking on the byte-count add, so do_update asserts it in debug builds

sm3: reinstate HMAC-SM3 under the per-crate layout the merge introduc…

91b3054

…ed, as a new sm3::hmac module holding the HMACParams impl, the HMAC_SM3 alias and the OSCCA OID, with its criterion bench, factory and CLI wiring and known-answer tests restored alongside it

core, sha3: XOF extends Hash, so SHAKE128 and SHAKE256 are hashes; sq…

4053f21

…ueezing becomes its own type

sha3: pin the SHAKE block_bitlen and output_len values, which three m…

86819d7

…utants survived

core: XofOutput gains do_final and do_final_out, matching BC Java's d…

24ae9b4

…oFinal after doOutput

sha3: add cSHAKE128 and cSHAKE256 (SP 800-185 Sec 3) with the Sec 2.3…

517cd59

… encodings and cshake CLI subcommands

docs: record the cargo mutants scoping flags, the bc-test-data conven…

61d3d8e

…tions and the commit message style in CLAUDE.md

dghgit and others added 10 commits October 17, 2026 01:38

ascon: Ascon_AEAD128<Dir> is the struct; the alias goes

a46c741

The cipher type takes the spec spelling directly, `Ascon_AEAD128<Dir>`, in place of `AsconAEAD128<Dir>` plus an alias to it; the alias's usage example moves onto the struct. Assisted-by: Claude:claude-mythos-5-1

CLAUDE.md: lessons from the Ascon-AEAD128 refactors

53a837b

Assisted-by: Claude:claude-mythos-5-1

cipher: CcmPacket::do_encrypt_inplace, to match the decrypt side

a1cce55

Assisted-by: Claude:claude-mythos-5-1

cipher: gcm doc line caught by the CCM rename, restored

7084adb

Assisted-by: Claude:claude-mythos-5-1

Claude Opus 5.5 refactors of aes tests

166bffa

Claude Opus 5.5 added suspended state tests for all AES key sizes.

6994217

Added tests that all the wycheproof failure cases zero-out the buffer…

21f5daf

…, as required by the library fn contracts.

Made ascon tests match AES tests. Assisted-by: Claude Opus 5.5

0b43d4e

ounsworth reviewed Oct 21, 2026

View reviewed changes

Comment thread cli/src/aes_cbc_cmd.rs Outdated

ounsworth added 2 commits October 21, 2026 12:40

Refactored cli/main.rs so that all subcommands are sorted alphanumeric

392ff73

De-duplicated AES benches from 54 down to 14

c62a964

ounsworth reviewed Oct 21, 2026

View reviewed changes

ounsworth added 2 commits October 21, 2026 16:23

Refactored the AES CLIs to use the public type aliases and not use ha…

2117605

…zmat::AESInternal

Added some possible enhancement notes for cipher::modes

fd97c99

ounsworth reviewed Oct 21, 2026

View reviewed changes

Comment thread crypto/cipher/src/modes/mod.rs

ounsworth and others added 5 commits October 21, 2026 17:49

Updated the instructions on cipher::modes::mod.rs::ModeNames with ins…

2cde0d2

…tructions for what to do for a permutation that does not impl all modes

Deleted cipher::padding standalone benches

9bb1744

Small adjustments to bouncycastle-cipher crate namespace and docs.

f2ff622

Moved ghash out of ghash.rs and into a private module within gcm.rs, …

5d4d6f4

…since that's its only consumer

ounsworth reviewed Oct 22, 2026

View reviewed changes

Comment thread crypto/core/src/traits.rs Outdated

ounsworth reviewed Oct 22, 2026

View reviewed changes

Navigation Menu

Repository navigation

Simple ciphers: stream + symmetric cipher unification off the release branch, plus SHA-512/t for any t - #133

Simple ciphers: stream + symmetric cipher unification off the release branch, plus SHA-512/t for any t#133
dghgit wants to merge 314 commits into
release/0.1.3alphafrom
feature/simple-ciphers

dghgit commented Sep 16, 2026

Uh oh!

Uh oh!

ounsworth Oct 21, 2026 •

edited

Loading

Uh oh!

Uh oh!

ounsworth Oct 22, 2026 •

edited

Loading

Uh oh!

ounsworth Oct 22, 2026 •

edited

Loading

Uh oh!

ounsworth Oct 22, 2026 •

edited

Loading

Uh oh!

ounsworth Oct 22, 2026 •

edited

Loading

Uh oh!

ounsworth Oct 22, 2026 •

edited

Loading

Uh oh!

dghgit Oct 23, 2026

Uh oh!

Uh oh!

ounsworth Oct 22, 2026 •

edited

Loading

Uh oh!

ounsworth Oct 22, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -28,16 +28,24 @@

		use crate::{AlgorithmFactory, FactoryError};

Conversation

dghgit commented Sep 16, 2026

New in this PR, on top of those two

Verification

Note for reviewers

Uh oh!

Uh oh!

ounsworth Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ounsworth Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ounsworth Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ounsworth Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ounsworth Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ounsworth Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dghgit Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ounsworth Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ounsworth Oct 22, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ounsworth Oct 21, 2026 •

edited

Loading

ounsworth Oct 22, 2026 •

edited

Loading

ounsworth Oct 22, 2026 •

edited

Loading

ounsworth Oct 22, 2026 •

edited

Loading

ounsworth Oct 22, 2026 •

edited

Loading

ounsworth Oct 22, 2026 •

edited

Loading

ounsworth Oct 22, 2026 •

edited

Loading