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

[dghgit]

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

[ounsworth]

This is cute to impl Algorithm once for AES128, but that's not right. The ALG_NAME on the AES_GCM_128 object needs to be "AES_GCM_128", not "AES_128".

If we're going to say that "AES_CBC_128" and "AES_GCM_128" are different algorithms with different key types (which we really should), then those need separate Algorithm impls.

Looking at your complicated tower of definitions, we'd need to impl Algorithm on this:

pub type AES_CBC_128<Dir, Pad> = <Dir as Direction>::Select<
    PaddedBlockCipherEncryptor<
        Cbc<AES128Internal, Encrypting, 16, AES_BLOCK_LEN>,
        Pad,
        16,
        AES_BLOCK_LEN,
        AES_BLOCK_LEN,
    >,
    PaddedBlockCipherDecryptor<
        Cbc<AES128Internal, Decrypting, 16, AES_BLOCK_LEN>,
        Pad,
        16,
        AES_BLOCK_LEN,
        AES_BLOCK_LEN,
    >,
>;

Looking at the current user docs in aes/src/cbc.rs, we have:

type Enc = AES_CBC_128<Encrypting, NoPadding>;

let key = KeyMaterial128::from_bytes_as_type(&[0x42; 16], KeyType::SymmetricCipherKey).unwrap();

// A whole block is fine, and comes out the same length.
let mut out = [0u8; 16];
let (_iv, written) = Enc::encrypt_out(&key, &[0u8; 16], &mut out).expect("aligned");

Then, that type Enc = AES_CBC_128<Encrypting, NoPadding>; should impl Algorithm; ie you should be able to do Enc::ALG_NAME which should be "AES_CBC_128" and Enc::MAX_SECURITY_STRENGTH which should be "_128bit", because after all, AES_CBC_128 is an algorithm.

[officialfrancismendoza]

@ounsworth Agreed. I changed the mode types so each user-facing AES alias now has its own Algorithm::ALG_NAME (AES_CBC_128, AES_GCM_128, etc.) while preserving the appropriate security strength.

I added a ModeNames trait in the cipher crate that the AES internals implement, and each mode's Algorithm impl picks up its corresponding name from there.

The diff is unfortunately a bit larger than the conceptual change because adding that bound required updating the generic mode types/tests. I also added a cipher-local test block cipher rather than generating future technical debt for core. The alternative would've put mode-specific knowledge into core::ElectronicCodeBook (or otherwise making core depend on the set of modes defined by the cipher crate), which would require rewrites for new updates.

All public AES mode aliases now have mode-specific algorithm names and the workspace tests pass aside from the unrelated local Ascon vector issue.

Handled in commit 79c859d

[officialfrancismendoza]

@ounsworth Also fixed the specific key issue you raised; valid given there was no strict counter to cross-algorithm reuse.

Each public AES mode now reports its own ALG_NAME (AES_CBC_128, AES_GCM_128, etc.) while preserving the appropriate security strength.

I also added opt-in algorithm binding to KeyMaterial: an unbound SymmetricCipherKey preserves existing behavior, but once bound to (say) AES_CBC_128, GCM/other modes will reject it. Changing/removing a binding requires do_hazardous_operations. Chose an opt-in solution to preserve reverse-compatibility to the existing API design without invasive changes, but also to enable certain operations, including but not limited to:

• Key generation/storage APIs that produce or persist “a 128-bit symmetric key” before a caller chooses CBC vs GCM.
• Generic test/framework code that only cares about key length/type and passes the key into some P: Algorithm.
• Low-level primitives like AES128Internal, where the key is for raw AES rather than specifically CBC/GCM.
• APIs that derive/import a key and then decide later which construction uses it.
• Key-management code that needs to move/store keys without depending on every cipher mode type.

With strict binding, all of those must know the final algorithm name up front (and would blow up the existing SymmetricCipherKey).

To avoid coupling core to the cipher crate's modes, ModeNames remains cipher-local and I moved the toy block cipher into the cipher tests rather than adding mode-specific metadata to ElectronicCodeBook.

Workspace tests pass except the existing local Ascon Wycheproof failure from the missing vector file.

Handled in commit 0de70ae