[roy-basmacier]

Adds the three BLAKE hashes requested in #123 for OpenSSL provider provisioning: two new crates, wired into the factories, the CLI and the stack-memory benches. Base: release/0.1.4alpha, rebased onto 6144224 (the #194 MAC rework). Other BLAKE2 digest lengths, salt/personalisation, BLAKE2bp/sp/X and tree mode are out of scope.

blake2 (new crate bouncycastle-blake2):

• BLAKE2b_512 and BLAKE2s_256 implement Hash and Suspendable. G, F, the parameter block and the final-t rule are commented against RFC 7693 s. 3.1-3.3, and blake2b.rs and blake2s.rs are kept structurally identical.
• The native keyed mode (not HMAC): the key objects BLAKE2b_512_MACKey and BLAKE2s_256_MACKey (FromAnyKeyMaterial, MacGenerationKey, MacVerificationKey at N = 64 / 32) hand out BLAKE2b_512_MAC<'k, Dir> / BLAKE2s_256_MAC<'k, Dir> workers. Key checks run in the order type, strength, length (1..=64 / 1..=32).
• AlgorithmOID: id-blake2b512 and id-blake2s256 (RFC 7693 s. 4), on the hash and MAC types.
• Suspended hash states are 212 bytes (BLAKE2b-512) and 108 bytes (BLAKE2s-256). Resume refuses an h that is not the unkeyed initial state at t == 0 (constant-time compare, which also catches a keyed initial state), a t that is not a whole number of blocks or lies in the upper half of its range (so a resumed state cannot wrap the counter), and an empty buffer after a compression.

blake3 (new crate bouncycastle-blake3):

• BLAKE3 implements Hash and XOF in hash mode, and BLAKE3Squeezer streams the extended output. Both are Suspendable, with states of 1874 and 116 bytes. Hash resume refuses any chunk-state / CV-stack combination no input produces, including an empty chunk after the first. Squeezer resume accepts only a root a tree can have (a parent node with a 64-byte block, or a chunk's last block), refuses an output block counter above 2^58 (s. 2.6: output is below 2^64 bytes) so a resumed stream can never wrap, and recomputes the partly read output block instead of storing it.
• derive_key is its own type, BLAKE3DeriveKey (Hash + XOF, constructed with a context string). It and its squeezer BLAKE3DeriveKeySqueezer are deliberately not Suspendable, because their state would contain key material. compile_fail doctests pin this.
• keyed_hash: the key object BLAKE3KeyedHashKey (exactly 32 bytes) hands out BLAKE3KeyedHash<'k, Dir> workers, which read the key words through the borrow; the generator keeps an inherent into_squeezer for extended keyed output. BLAKE3KeyedSqueezer is neither Suspendable nor Clone.
• The engine follows the reference implementation's chunk state and its 54-entry chaining-value stack (spec s. 2.4-2.6, 5.1). Chaining values and compression outputs outside the compression function are held in Secrets (key-derived in the keyed modes); the compression function's own working state is not zeroized, as in SHA-2 and BLAKE2 (doing so cost about 10% more instructions per MiB).

Both crates:

• The MAC workers follow The MAC worker splits into MACGenerator and MACVerifier, with the tag length in the type #194: Dir = Encrypting implements MACGenerator, Dir = Decrypting MACVerifier; the tag is the full 64 / 32 / 32 bytes as an array, with no run-time truncation; verification returns Result<(), MACError> and recomputes the tag into a Secret. The workers borrow their key (BLAKE2's still copy the keyed state, which they advance), and implement neither Suspendable nor Clone, per QUALITY_AND_STYLE.md; a MAC in progress is paused by holding its worker.
• Every _out function zeroizes its buffer before any error check. Partial-bit input: 0 bits is a whole-byte message, 1..=7 returns InvalidInput, and more returns InvalidLength.
• Each crate's Memory Usage section gives the object sizes, the suspended-state lengths and the measured peak stack per operation (stack painted below a non-inlined call, release with thin LTO, x86_64, rustc 1.97.0-nightly): BLAKE2b about 1.1 KB and BLAKE2s about 0.7 KB, BLAKE3 about 5-7 KB, and BLAKE3 suspend+resume about 11.7 KB.

factory: HashFactory gains BLAKE2b-512, BLAKE2s-256 and BLAKE3; XOFFactory gains BLAKE3; MACFactory and MACFactoryWorker<'k, Dir> gain the three BLAKE MAC keys and workers, with their tag lengths through TagLen.

Open question: the factory enums' size. HashFactory and XOFFactory are 1888 bytes and MACFactoryWorker 1872, because BLAKE3's hasher carries a 1728-byte chaining-value stack sized for the full 2^64-byte input range (spec s. 5.4). Without BLAKE3 the largest variant is a SHA-3 or KMAC state of at most 440 bytes. An enum is as large as its largest variant, so every HashFactory / XOFFactory user pays this on its stack whichever algorithm it selects, and every move copies all of it. The factory crate's Memory Usage section documents it; nothing is changed yet. Options:

1. Keep it, documented (the PR as it stands).
2. Box the BLAKE3 variants: the enums go back to about 440 bytes, at the cost of a heap allocation for BLAKE3 and one more obstacle to no_std.
3. Give BLAKE3 a smaller CV stack in the factory, capping its input there (an error path the other hashes do not have).
4. Leave BLAKE3 out of HashFactory and XOFFactory, reachable only as its own type.

cli: blake2b-512, blake2s-256, blake2b-512-mac, blake2s-256-mac, blake3, blake3-keyed-hash and blake3-derive-key, all streaming (blake3-keyed-hash streams stdin in and the squeezed output out). cli/tests/test_blake.sh adds 17 tests on the shell harness. The BLAKE key loader reads --key / --key-file through the same load_secret as the HMAC/KMAC loader, so --key-file wins everywhere, as the help text says (test_hmac.sh pins this). It adds a per-algorithm length check with a message naming the limit. Both loaders warn on an all-zero key through one helper. That also fixes the HMAC/KMAC warning, which never fired: it tested for KeyType::Zeroized, and loaded keys are tagged Unknown.

tests: RFC 7693 Appendix A/B, selections from the official BLAKE2 KAT, the bc-test-data Blake2KAT.txt sweep (512 + 512 records), all 35 official BLAKE3 vectors in all three modes, and the core-test-framework suites for Hash, XOF, MAC keys, key construction and suspend/resume. Wycheproof has no BLAKE vectors. cargo mutants (apollo, 5014bcc; the later commits add mutants notes and docs only): blake2 326 tested, 244 caught, 70 unviable, 12 missed, all equivalent and noted at the site (two of them on the new t bound); blake3 422 tested, 342 caught, 61 unviable, 10 missed, 9 timeouts (mutants that make a fill or merge loop never end), every miss an equivalent noted at the site (one new, on the squeezer's buffer recompute); factory mac_factory.rs 55 tested, 25 caught, 30 unviable, 0 missed.

#![no_std] remains a todo in both crates, as in every hash crate, blocked by the Vec return types in core::traits::Hash.

Rebase onto 6144224: the six commits were replayed (the earlier merge commits of release are gone), with mac_factory.rs and its tests kept at the release's version during the replay, so the replayed commits in between do not build; the tip does. The port to the #194 traits is its own commit, followed by the review fixes below.

Review of 9059e06 (findings 1-9):

1. BLAKE2 hash/MAC states interchangeable once t > 0: moot, because the MAC workers no longer suspend, so there is no MAC state to swap. With that gone the kk byte had nothing left to guard and was dropped from the state; the t == 0 check still refuses a keyed initial h.
2. derive_key state holds the IKM: fixed, since BLAKE3DeriveKey and its squeezer are not Suspendable.
3. Squeezer counter wrap: fixed, since resume refuses a counter above 2^58.
4. t > 0 && buf_len == 0 accepted: fixed, InvalidData in both BLAKE2 variants.
5. Non-constant-time resume compares: fixed. The keyed compares went with keyed suspend, and the remaining h and IV checks use ct_eq_bytes.
6. CLI loaders with opposite precedence: fixed. Both read through load_secret (file wins) and share the zero-key warning. The BLAKE loader stays separate only for its length range.
7. Factory enums at 1888 bytes: still open, see the question above.
8. Repeated spec quotes: fixed. Each quote now has one home, on the Algorithm impl.
9. Duplicate MIN_MAC_OUTPUT_LEN: gone with tag truncation in the port to The MAC worker splits into MACGenerator and MACVerifier, with the tag length in the type #194.

Review of 40aebcf (2026-11-10), all fixed:

1. Keyed workers were Clone: the BLAKE MAC workers and BLAKE3KeyedSqueezer no longer are; compile_fail doctests pin the workers.
2. BLAKE2 resume did not bound t: a forged t near the top wrapped the counter (a debug panic, a wrong digest in release); a t in the upper half of its range is now refused.
3. BLAKE3 squeezer resume trusted a stored output buffer: the buffer is no longer stored and is recomputed.
4. BLAKE3 squeezer resume accepted impossible root flags: only a parent node (b = 64) or a chunk's last block is accepted.
5. BLAKE3 hash resume accepted an empty chunk after the first: refused.
6. Verifiers left the recomputed tag in an unzeroized Vec: it is a Secret array.
7. BLAKE2 suspend/resume staged state in plain arrays, and BLAKE3's keyed-mode chaining values were plain locals: Secrets now.
8. blake3-keyed-hash panicked on a stdin read error and held the whole --length output: it streams through the shared helpers.
   Also from that review: the workers borrow their key, and public docs no longer carry internal detail (state layouts, other implementations' conventions).

Review of d279232 (2026-11-10, seven findings, no correctness bug):

1. The MAC keys' generate repeated HMAC's and KMAC's draw-and-cap closure: fixed in core, KeyMaterial::from_rng_as_type(rng, len, key_type) is the one draw (from_rng wraps it), and the five generates are a line each.
2. warn_if_zeroized_key hand-rolled the all-zero check: fixed, it uses bouncycastle_utils::ct::ct_eq_zero_bytes.
3. load_blake_mac_key was a third MAC-key loader beside load_mac_key and load_key_object_typed, tagging the same bytes differently: fixed, helpers::load_mac_key(key, key_file, len) is the one MAC loader, with the length bound a parameter (None for HMAC and KMAC); the block ciphers' typed loader stays, being a different shape.
4. BLAKE2's h_ct_eq re-serialized both sides to compare h with the initial state: fixed, from_suspended compares the state's own h bytes with the serialized constant, as BLAKE3 does, and h_ct_eq is gone.
5. Err(..)? beside return Err(..) in BLAKE3KeyedHashKey's checks: fixed.
6. Factory enum size: the open question above.
7. Public from_suspended docs listed internal state combinations: fixed, they say a state the type did not produce is InvalidData; the checklist lives on the private read_state (BLAKE3) or at the checks themselves (BLAKE2, whose read_state doc defers to them), and the BLAKE2 state-length constants carry their layout as a code comment, as BLAKE3's do, not as public docs.

cargo mutants after the three commits (apollo): blake2 310 (230 caught, 70 unviable, 10 missed, the noted equivalents), blake3 417 (338 caught, 61 unviable, 9 missed, 9 timeouts, as noted), core from_rng / from_rng_as_type with the core, hmac and blake2 tests 10 (6 caught, 4 unviable, 0 missed).

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

[dghgit]

Merged release/0.1.4alpha (now at 563978a, the fix/supplied-nonce squash) into this branch and pushed 25e7334 to the PR head. The merge also brought in the #192 squash, which removed SuspendableKeyed from core, so a follow-up commit drops the BLAKE2b-512 MAC, BLAKE2s-256 MAC and BLAKE3 keyed-hash impls of it along with their state-length constants, docs and tests; the hash types and the BLAKE3 squeezer keep Suspendable as before. Workspace build, tests, rustdoc, rustfmt and test_blake.sh (16/16) pass on the new tip.

[dghgit]

Third review, at d279232, by the project's code-review pass at high effort. The reviewer checked out the head in a scratch worktree: blake2, blake3 and factory tests pass with no warnings, the criterion and stack benches compile, the mem-bench doctests pass, and the CLI reproduces RFC 7693 Appendix A and the official BLAKE3 hash / keyed_hash vectors (cli/tests/test_blake.sh 17/17). No correctness bug in the compression functions, the incremental engines, the suspend/resume validation or the CLI; checked and sound: the RFC 7693 G/F transcription and SIGMA[i mod 10], the BLAKE2 counter semantics (t at the end of a block, the key block counted, empty keyed and unkeyed finals), the hold-one-byte-back invariant and its mirror in read_state, the BLAKE3 chunk and CV-stack logic, parent counter 0, ROOT applied only at output, derive_key's two-stage keying, the squeezer's recompute of block counter - 1, the factory wiring and TagLen, the CLI names and the --verify plus --length refusal.

Seven findings, on reuse, altitude and proportion. Six are fixed in the four commits above d279232 (5626d71, d3adf8e, c5b23f6, 667ced1); the seventh is the open question in the body.

1. One key draw for every MAC key's generate (d3adf8e). The BLAKE2b, BLAKE2s and BLAKE3 keys' generate were a fourth and fifth copy of the twelve-line hazardous-operations closure HMAC and KMAC carry (draw len bytes into a longer buffer, set the length, tag MACKey, cap the strength at the lesser of the RNG's and the length's), while KeyMaterial::from_rng in core did the same draw with CryptographicRandom hard-coded. core gains KeyMaterial::from_rng_as_type(rng, len, key_type): len at most the capacity (else InputDataLongerThanKeyCapacity), the caller's type, SP 800-90A r1 Section 8.4's min(output_length, DRBG_security_strength), a zero len back Zeroized without touching the RNG. from_rng is that call with KEY_LEN and CryptographicRandom, and all five generate impls (HMAC, KMAC, BLAKE2b, BLAKE2s, BLAKE3) are one line over it, so the capping rule has one home. A core test covers the shorter typed draw, the cap, the zero draw and the capacity refusal; the MAC crates' own generate tests are unchanged.
2. The CLI's zero-key warning hand-rolled an OR fold the optimiser may shorten: it uses bouncycastle_utils::ct::ct_eq_zero_bytes, barrier-hardened and already the MAC commands' comparison (5626d71).
3. One MAC key loader (c5b23f6). load_blake_mac_key was a third loader beside mac_cmd::load_mac_key and the block ciphers' load_key_object_typed, and the two MAC loaders tagged the same bytes differently (BLAKE keys got a length-derived strength and a second 64-byte copy). helpers::load_mac_key(key, key_file, len) is now the one loader, len the algorithm's bound where it has one (BLAKE2b 1 to 64, BLAKE2s 1 to 32, BLAKE3 exactly 32) and None for HMAC and KMAC; the block ciphers' loader stays, being a typed fixed-length key object.
4. BLAKE2's h_ct_eq re-serialized both sides to compare h with the unkeyed initial state: from_suspended compares the state's own h bytes with the serialized constant, as BLAKE3's resume compares its IV, and h_ct_eq is gone from both files (5626d71).
5. Err(..)? beside return Err(..) in BLAKE3KeyedHashKey's checks: spelled out like its neighbours (5626d71).
6. The factory enums' size (HashFactory and XOFFactory about 1888 bytes, MACFactoryWorker 1872, from BLAKE3's 1728-byte CV stack): the open question in the body. The reviewer leans towards a CV stack sized to a documented input cap (2^40 bytes gives 30 CVs, about 1 KB saved) over keeping the full depth; still to decide.
7. Public from_suspended docs on BLAKE2b_512, BLAKE2s_256 and BLAKE3Squeezer listed the internal state combinations they refuse, which a caller cannot act on: they say a state the type did not produce is InvalidData (5626d71). The checklist has one home per file: BLAKE3's private read_state doc, and for BLAKE2 the comment at each check, with read_state's doc deferring to them; the BLAKE2 state-length constants carry their layout as a code comment, as BLAKE3's already did, instead of public rustdoc (667ced1).

Verified after the four commits (the fourth is docs and comments only): core, hmac, sha3, blake2, blake3, factory and core-test-framework suites; test_blake.sh 17/17, test_hmac.sh 6/6, test_kmac.sh 7/7, test_aes_mac.sh 6/6; the workspace builds every target; core's rustdoc; fmt; clippy adds nothing on the changed lines. Mutants (apollo): blake2 310 (230 caught, 70 unviable, 10 missed: the equivalents noted at the site, five per file, 16 mutants fewer than before with h_ct_eq and the draw closure gone); blake3 417 (338 caught, 61 unviable, 9 missed, 9 timeouts: the noted flag-bit |/^ swaps, the squeezer recompute's </<=, and the fill and merge loops that never end, one miss fewer than before); core from_rng / from_rng_as_type with the core, hmac and blake2 tests 10 (6 caught, 4 unviable, 0 missed).

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

[dghgit]

Rebased and reviewed with Mythos. A handful of minor issues fixed as described.

[dghgit]

Squash-merged onto release/0.1.4alpha as c999768 (tree identical to 667ced1, author royb). The factory enum size question stays as option 1, documented in the factory crate's Memory Usage section. Closing by hand, as the merge happens on the private upstream.