[dghgit]

Two-party key agreement on the key objects, in the shape feature/kem-rework gives the KEM traits (this PR is stacked on it), and bouncycastle-eccdh, the ECC CDH primitive of SP 800-56A Rev. 3 Section 5.7.1.2 over seven curves on those roles, with its CLI and stack harness: Phases 3 to 7 of the ECC CDH plan. One commit per crate group, each with its mutants figures.

What changes

core, core-test-framework (the API)

• core::agreement_key: AgreementKey<Params, SS_LEN>, implemented once per algorithm on a private key over the parameters a worker is made from, () for the raw primitive and the caller-configured KDF for an algorithm that derives its output, so the parameter type selects the impl at the call and both parties name the same one. Each impl names type Algorithm: KeyAgreementAlgorithm and type PublicKey, produces the worker as a GAT borrowing the key through create_agreement(&'k self, params), and gets agree(&peer_pk, params) provided. Two parties only; MQV and the multi-key schemes of Section 6 are not expressed.
• core::traits::KeyAgreement<PK, SS_LEN>: the worker, AlgorithmInfo supertrait, agree(&self, &PK) returning Z as KeyMaterial<SS_LEN> typed KeyType::SharedSecret (for a KDF and nothing else, Section 5.8), reusable, dyn-compatible. KeyAgreementPrivateKey / KeyAgreementPublicKey are the encodable key traits, with the public key's decoder carrying the algorithm's validation. KeyAgreementError with AgreementFailed for Section 5.7.1.2 step 2.
• Framework suite: both parties compute the same secret, typed full-entropy material at the algorithm's strength (the raw primitive's SharedSecret or a KDF-bearing algorithm's derived key; the implementor's tests pin which); the worker gives the one-shot's value, carries the metadata, is reusable and works as a trait object; a third party differs; a keys suite round-trips the encodings. An in-file mock Diffie-Hellman over a 61-bit prime, made from a borrowed parameter, runs it.

eccdh (11d229a)

• The new crate crypto/eccdh, bouncycastle::eccdh, over P-256, P-384, P-521, secp256k1, brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1, built on bouncycastle-ec's arithmetic, SEC 1 codecs and constant-time multipliers. Per curve: its own key pair (ECCDHP256PrivateKey / ECCDHP256PublicKey and siblings; distinct from the ECDSA types, since Section 5.6.3.2 item 5 does not let one pair serve both purposes), the marker (ECCDHP256, ECCDHSecp256K1, ECCDHBp256r1, ..., named "ECC-CDH-P256" and so on), the worker a private key hands out over (), and keygen by extra random bits (Section 5.6.1.2.1, L = len(n) + 64 bits, the RBG checked against the curve's strength).
• A private key loads only in [1, n-1] (Section 5.6.2.1.2). A public key is fully validated at decode (Section 5.6.2.3.3 steps 1 to 3 through the ec decoders); step 4 is argued, not computed, because every curve here has cofactor 1 (SP 800-186 Section 3.2.1, SEC 2 v2 Section 2.4.1, RFC 5639 Sections 3.4, 3.6 and 3.7), so a point on the curve other than the identity has order n.
• agree follows Section 5.7.1.2 line by line: [d]Q in constant time, the identity test kept on a condition no validated input reaches and acted on after the intermediates are zeroized, x_P through a branch-free affine conversion and Appendix C.2's conversion, and Z typed SharedSecret at the curve's strength (an all-zero Z comes back Zeroized, not an error).
• The P-256 keys implement the role a second time as ECCDHP256_HKDF_SHA256, Z through HKDF-SHA256 with the caller's salt and info, the shape of feature/kem-rework's ML-KEM pairings (now over KdfParams<HKDF_SHA256>, below); every curve also carries the X9.63 and concatenation KDF pairings described below, and the raw Z is there for any other KDF. keys_common::DerivePublicKey recomputes Q = [d]G for the CLI. A short example, examples/p256_key_agreement.rs, replaces the ec crate's earlier sketch of the roles over its hazmat API (deleted, with the dev-dependencies it alone needed).
• The 0.1.4 release notes carry the entry.

cli (fefce52)

• eccdh-p256 .. eccdh-bp512r1: one generic eccdh_cmd over the key traits and the role, with keygen, pk-from-sk, check-consistency (Section 5.6.2.1.4 method (b)) and agree, which writes the raw Z for a KDF (hkdf-* --ikm-file, x963kdf-* --ikm-file, concatkdf-* --ikm-file; never the inline --ikm, which would leave Z in the command history).

mem_usage_benches (8909d12)

• bench_eccdh_mem_usage: the fourteen key types' sizes and one keygen or agree per curve under a non-inlined measure wrapper. The crate docs' stack table is the deepest frame chain below it (frame-layout remarks plus the binary's call graph, the method of the cipher crates' tables): agree 4,216 / 5,736 / 8,520 / 4,056 / 4,312 / 5,712 / 7,600 bytes for P-256 / P-384 / P-521 / secp256k1 / bp256r1 / bp384r1 / bp512r1, keygen 2,600 / 2,232 / 5,352 / 2,424 / 2,712 / 2,528 / 4,672.

x963kdf, factory, cli (9fdf234, 8278197, 0e196f1)

• The new crate crypto/x963kdf, bouncycastle::x963kdf: X963KDF<H>, SEC 1 v2 Section 3.6.1 line by line, K_i = Hash(Z || Counter || [SharedInfo]) with the 4-octet counter from 1, keydatalen checked against step 2's bound and the buffer, each block hashed by streaming rather than concatenating, one block held in a Secret; the entropy accounting is HKDF's (full-entropy once half a hash output of typed material has gone in, at the least of Z's, the hash's and the length's strengths). derive_out is the function and the KDF trait runs it, SharedInfo as the fixed info and the multi-key forms concatenating their keys as Z. Over the four SHA-2 hashes of Section 3.5 as X963KDF_SHA224 .. X963KDF_SHA512 ("X963KDF-SHA256" and so on). (X963KdfParams was the agreement parameters until KdfParams, below.)
• KDFFactory gains X963KDF-SHA256, -SHA384 and -SHA512 (SHA-224 left out as HKDF-SHA224 is); CLI x963kdf-sha256, -sha384, -sha512, the hkdf-* inputs minus the salt.

eccdh (0d48ad6): SEC 1 Section 6.1's ECDH scheme on every curve

• Each curve's keys implement the role a further time over the X9.63 KDF, the hash matched to the curve's strength: ECCDHP256_X963KDF_SHA256, ECCDHP384_X963KDF_SHA384, ECCDHP521_X963KDF_SHA512, ECCDHSecp256K1_X963KDF_SHA256, ECCDHBp256r1_X963KDF_SHA256, ECCDHBp384r1_X963KDF_SHA384, ECCDHBp512r1_X963KDF_SHA512 ("ECC-CDH-P256-X963KDF-SHA256" and so on), Z then KDF(Z, SharedInfo) at one hash output, so sk.agree(&peer_pk, KdfParams::new(&x963kdf, shared_info)) on a P-256 key needs no annotation and a KDF the curve is not paired with is a compile error.

concatkdf, factory, cli, eccdh (475a58c, 64264b3, 603330c, d671502): SP 800-56A Rev. 3 Section 5.8's one-step derivation

• The new crate crypto/concatkdf, bouncycastle::concatkdf: ConcatKDF<H>, the one-step KDF of SP 800-56C Rev. 2 Section 4.1, Option 1, with H(x) = hash(x), line by line: L > 0 (step 1), reps at most 2^32 - 1 (step 2, as MAX_LEN in bytes), the 4-byte big-endian counter from 1, K(i) = H(counter || Z || FixedInfo) streamed into the hash, the leftmost L bits written into the caller's buffer, zeroized first. Over the Table 1 hashes the library has: SHA-224 to SHA-512/256 and SHA3-224 to SHA3-512, as ConcatKDF_SHA256 and so on ("ConcatKDF-SHA256", "ConcatKDF-SHA3-256"). The entropy accounting is the X9.63 KDF's.
• KDFFactory gains the six SHA-2 and SHA-3 arms (ConcatKDF-SHA256, -SHA384, -SHA512, -SHA3-256, -SHA3-384, -SHA3-512); CLI concatkdf-sha256, -sha384, -sha512, -sha3-256, -sha3-384, -sha3-512, the x963kdf-* inputs.
• Each curve's keys implement the agreement role a further time over the concatenation KDF matched to the curve's hash: ECCDHP256_ConcatKDF_SHA256, ECCDHP384_ConcatKDF_SHA384, ECCDHP521_ConcatKDF_SHA512, ECCDHSecp256K1_ConcatKDF_SHA256, ECCDHBp256r1_ConcatKDF_SHA256, ECCDHBp384r1_ConcatKDF_SHA384, ECCDHBp512r1_ConcatKDF_SHA512 ("ECC-CDH-P256-ConcatKDF-SHA256" and so on), through the existing KdfParams<ConcatKDF_SHA256, LEN> role impl.
• Tests: the NIST ACVP KDA OneStep SP800-56Cr2 sample set (150 records: SHA2-224, SHA2-512 and SHA3-512, AFT and VAL, FixedInfo as the ACVP KDA specification builds it; crypto/acvp/KDA-OneStep-Sp800-56Cr2 in bc-test-data, the suite fails rather than skips without it), the core KDF framework's suites, the counter and truncation by hand across block boundaries, one block of every instantiation against its hash, the bounds, the entropy accounting, FixedInfo selecting the key; per curve the framework's agreement suite over the params and the derived key against ConcatKDF::derive_out over the raw Z; the factory arms against the aliases; cli/tests/test_concatkdf.sh (the ACVP SHA2-512 case through hex, file and binary paths, the SHA3-512 case through hex, hashlib-computed answers for the other four commands, the bound, and eccdh-p256's Z into concatkdf-sha256 on both sides). Mutants (apollo): concatkdf 40 (29 caught, 8 unviable, 3 missed, equivalents), eccdh kdf.rs 17 (3/6/8, all in x963_max_len's const-only arithmetic and derive's defensive check).

merge of feature/kem-rework (2c1c80a, c5cd567): takes the KDF trait reshaping (4edb0a7 there, with its test commits); the X9.63 crate and the factory's arms follow the &self, &dyn and explicit-length shape.

Rebased onto release/0.1.4alpha at f3fdb8b, the squash of PR #192 (2026-11-08, tip e3e9239): the merge commits that had brought feature/kem-rework into this branch drop out, the 24 eccdh commits are replayed, and one commit holds the three adaptations those merges had carried (eccdh's direct hkdf dependency gone, the KDF factory's X9.63 arms on the reshaped trait without the SHA-3 ones, the X9.63 tests on the &self shape). The change from the previous tip to this one is exactly kem-rework's final seven commits, checked file by file. What the merges took, for the record (9bbb5f5, d7a1763, defd754, 0046464, c83f78c, 444000d in the old history): c83f78c took the 2026-11-08 re-review round of PR #192 (SHA-3 and SHAKE no longer a KDF, so the factory keeps the X9.63 arms and loses theirs; the empty-key-list refusal, which x963kdf follows in 8aab6ba; and KdfParams<'p, K, LEN> with KeyLen, which eccdh follows in 8c43584: the pairings generic over the length, D bound by a sealed PairedKdf with MAX_LEN, the derivation under a const assert, a P-256 length test). Earlier: the last two take the fixes from the 2026-11-08 review of PR #192, and x963kdf follows the KDF rule (db6072b, f88abb8: a key with no strength credits nothing, a zero-length derivation is refused, the docs' Z states its strength). d7a1763 takes the SuspendableKeyed removal and the release's signature-worker dyn change, with core's dyn test keeping the key-agreement, KEM and signature checks. 9bbb5f5 takes KdfParams (e859b14 there). The ECC CDH keys implement the agreement role once per curve over KdfParams<'p, D>, bound on the sealed eccdh::kdf::KdfPairing<D, SS_LEN> a curve's marker implements once per KDF it is paired with (the X9.63 KDF over the matched hash on every curve, HKDF-SHA256 on P-256), with one worker type per curve (ECCDHP256KdfAgreement and siblings) and the derivation shared in kdf::derive; the per-KDF workers and impls go, X963KdfParams goes from x963kdf, and eccdh's hkdf dependency with it. A further pairing on a curve is one marker and one impl KdfPairing. The example runs HKDF-SHA256 and the X9.63 KDF on the same P-256 keys. 444000d took the round-3 fixes and the KEM _out forms, and the agreement roles followed: KeyAgreement::agree_out(peer_pk, ss) is the primitive with agree provided over it, on the worker and on AgreementKey, each _out zeroizing its buffer first and leaving it so on error; kdf::derive writes into the caller's buffer; the framework's agreement suite drives agree_out over prefilled buffers. Mutants (apollo, on the pre-rebase tip, same trees): core agreement_key.rs with the eccdh tests 10 (4 caught, 6 unviable, 0 missed); eccdh kdf.rs and the P-256 agree_out paths with the P-256 tests 14 (7 caught, 6 unviable, 1 missed: || to && on the two length checks in derive, equivalent for the sealed KDFs, as in mlkem-common).

Verification

• cargo test --workspace, cargo test --workspace --all-targets --no-run, rustdoc with no warnings, rustfmt (nightly), clippy adds nothing in the new code.

• Per curve: the framework's agreement and key suites (and over HkdfParams on P-256), derive_pk against keygen, the [1, n-1] boundary (0, n, n + 1, all ones refused; n - 1 loads), an off-curve point refused at decode, compressed encodings, a weak RNG refused and one at exactly the curve's strength accepted, keygen's determinism given the DRBG output, Z feeding HKDF to a CryptographicRandom PRK, and the HKDF variant against HKDF run by hand over the raw Z.

• Known answers: NIST CAVP ECC CDH primitive vectors (CAVS 14.1, 25 records each for P-256, P-384 and P-521, from crypto/cavp/KAS_ECC_CDH_PrimitiveTest.txt in bc-test-data; the suite fails rather than skips without it), RFC 7027 Appendix A.1 to A.3 for the brainpool curves from both sides, and Wycheproof ecdh_*_test.json for all seven curves plus the ecpoint sets for the NIST curves: 10 files, 7667 vectors (5608 valid, 1609 acceptable, 450 invalid), the SPKI handled by a strict DER walk in the test with a mismatched AlgorithmIdentifier treated as a key rejected at decode; the runner pins the number that reach the library and agree per file (the valid vectors and the one compressed-point acceptable vector) and fails if that compressed point is rejected.

• CLI: cli/tests/test_eccdh.sh 5 of 5 (CAVP P-256 and P-521 COUNT 0 through files, stdin and --hex-input; round trips on all seven curves; an off-curve peer key, d = 0 and a P-384 key under the P-256 command refused; Z through a file into hkdf-sha256 --ikm-file on both sides).

• Mutants (apollo), per curve on its keys_*.rs and eccdh_*.rs with the curve's own test binaries: P-256 55 (22 caught, 32 unviable, 1 missed), P-384 45 (19/25/1), P-521 45 (20/25/0), secp256k1 45 (19/25/1), brainpoolP256r1 45 (19/25/1), brainpoolP384r1 45 (19/25/1), brainpoolP512r1 45 (19/25/1). The miss on five curves was keygen's < on the RNG strength becoming <=, killed by the exact-strength test (confirmation run on the key files: 28 each, 15 caught, 13 unviable, 0 missed); brainpoolP512r1's is agree's guard around setting Z's strength (the all-zero Z arm), unreachable there because b is a quadratic non-residue mod that curve's p, so x_P = 0 is not on the curve; on P-521, where x_P = 0 is on the curve, the same mutant is caught by Wycheproof. (An earlier version of this body gave the length-derived default strength as the reason, which stopped holding once a SharedSecret took no strength of its own.) Core agreement_key.rs on the role trait: 6 (2 caught, 4 unviable, 0 missed).

• X9.63: the core KDF framework's suites on a CAVP vector, the counter and truncation against hand-computed Hash(Z || Counter || SharedInfo) across block boundaries, both length bounds, the entropy accounting (caps by Z, hash and length; the 31/32-byte threshold for SHA-512; Unknown credited nothing), and all 80 SHA-224/256/384/512 records of NIST CAVP ansx963_2001.rsp from bc-test-data's crypto/cavp (the suite fails rather than skips without it). cli/tests/test_x963kdf.sh 6 of 6 (CAVP records through hex, file and binary paths, the bound, and eccdh-p256's Z into x963kdf-sha256 on both sides). Per curve: the framework's agreement suite over the params, the derived key against X963KDF::derive_out over the raw Z, and the SharedInfo selecting the key.

• Mutants for the X9.63 work (apollo, before the merge): x963kdf crate 42 (21 caught, 19 unviable, 2 missed: Clone for the stateless type replaced by Default, equivalent, and a + in the last-block copy, killed since by a test deriving a partial last block into an exactly-sized buffer); eccdh per curve on its eccdh_*.rs with the curve's test binary: P-256 36 (10 caught, 26 unviable, 0 missed), P-384, secp256k1, brainpoolP256r1 and brainpoolP384r1 26 each (7/19/0), P-521 and brainpoolP512r1 26 each (6/19/1, the agree strength guard: unreachable on brainpoolP512r1 as above, and since caught by Wycheproof on P-521). After the merge (x963kdf on the reshaped trait): 36 (21 caught, 13 unviable, 2 missed: the Clone equivalent and step 2's * to +, which the bound test now distinguishes from the buffer check, a6a87a8; 22/13/1 on re-run, the equivalent remaining).

• After KdfParams (9bbb5f5, 7cb95db): cargo test --workspace, all targets built, rustdoc, rustfmt clean; the example and the eccdh, x963kdf and hkdf CLI suites pass. Mutants (apollo): eccdh kdf.rs 6 (2 caught, 4 unviable, 0 missed); per curve on its eccdh_*.rs with the curve's test binary 26 each: P-256, P-384, secp256k1, brainpoolP256r1 and brainpoolP384r1 7/19/0, P-521 and brainpoolP512r1 6/19/1 (the agree strength guard, as above); x963kdf crate 32 (22/9/1, the Clone equivalent).

Review round (2026-11-10, Megan's three-agent review of ea8b62e: 0 Bug, 8 Hardening, 10 Notes)

All eight Hardening items and the ten Notes are in, as per-crate commits above the merge of #194:

• H1, H3 from_bytes on every curve borrows its input, holds the limbs and the difference d - n in Secret, and makes the [1, n-1] check one masked decision (!nat::is_zero & is_equal(borrow, 1)) with no array comparison; ec's extra-random-bits reductions hold the DRBG output, its reduction and d in Secret too. In the x86-64 release assembly of P-256's from_bytes: no comparison routine, one barriered decision, both Secrets cleared on the accept, reject and unwind paths.
• H2 x_affine scrubs the square of the inverse, the limbs of z live in a Secret, and the crate docs now say which intermediates this crate destroys (P, z, the inverse and its square, the bytes) and that bouncycastle_ec's own are not reached, in place of the claim that step 4 was done.
• H4 Steps 2 to 5 moved into z_from_product(&mut P) so an in-file unit test per curve drives the identity path; the framework's mock rejects a context labelled 0 and a test drives agree_out over prefilled buffers through the worker, the role with the identity peer, and the role with the rejected context.
• H5 Each curve's ec SEC 1 test decodes (x + p, y) for a point on the curve after reduction (only the range check rejects it; the P-256 vector is the reviewers'), and the false comment in p256_sec1.rs (and sm2_sec1.rs) is corrected.
• H6 The Wycheproof runner pins the agreed count per file and requires the compressed point to agree. H7 The three X9.63 factory arms are checked against CAVP ansx963_2001.rsp known answers. H8 The eccdh help, module comment and shell test send Z through --ikm-file.
• Notes: the constant-time prose names the four secret-dependent decisions and is limited to optimised builds (N1); the pairing docs say what an all-zero Z yields through each KDF role (N2); the X9.63 and concatenation KDFs' edge is stated and pinned: no keys is refused, a key of length zero is derived from and yields Unknown output, the KDF trait's rule the framework suite holds every KDF to (N3); the step 1 wording gives SEC 1's hashmaxlen values, the multi-key doc no longer cites SP 800-56C, P-521's DRBG draw reads "74 bytes, 592 bits, at least the 585 asked", and the Status says secp256k1 and the brainpool curves are outside SP 800-56A's Appendix D and allowed by SP 800-186 Appendix H (N4); the Wycheproof split and the brainpoolP512r1 mutant's reason above are corrected (N5, N6); the pairing names are ECC-CDH-P256-X963KDF-SHA256 and ECC-CDH-P256-ConcatKDF-SHA256 throughout, the release notes name AgreementKey<Params, SS_LEN> (N6); the X9.63 step 2 test holds the bound itself, the weak-RNG tests use the strength one step below each curve's, two compile_fail doctests hold the KeyLen bounds, and the X9.63 KDF zeroizes on the (unreachable) error path after its block loop (N7); the bound tests no longer overflow a 32-bit usize (N8); the KeyAgreementError variants are documented and the framework structs have Default (N9); KeyAgreementError::KDFError carries the KDF's own error (N10). Not changed from N10: AgreementKey::PublicKey stays unbounded and agree / agree_out stay overridable, as the KEM roles are; #![no_std] stays nominal while core is std.
• Mutants (apollo): eccdh keys_p256.rs + eccdh_p256.rs 57 (25 caught, 32 unviable, 0 missed); ec p256_sec1.rs + p256_extra_bits.rs + p521_extra_bits.rs 52 (46 caught, 5 unviable, 1 missed: | to ^ on two non-overlapping bit ranges in P-521's fold, equivalent); core agreement_key.rs with the framework's and eccdh's tests 10 (4 caught, 6 unviable). The three hand mutations the review listed (the role's zeroize, the identity check, the range check) each fail one test.

Round two (same day, at 45422de: 0 Bug, 4 Hardening, 11 Notes, "ready to approve"): the five pre-merge items and the code behind R2-H1 to R2-H3, five commits (ec, eccdh, concatkdf, x963kdf, cli). Each ec scalar gains from_borrowed_limbs(&[u64; L]), reducing into its Secret in place (nat::sub_assign, Condition::mov), from_limbs delegates and wipes its parameter, and nat, barrett and montgomery gain in-place and out-parameter forms the keygen reduction now writes every step through, so what the dead-stack probe found in the by-value returns is gone and what remains is the returned scalar's move (R2-H1, R2-H2). The eccdh primitive is agree_out(sk, peer_pk, &mut ss), writing Z into the caller's buffer, with the KDF worker holding Z in a local it owns (R2-H3); the unit test drives the identity path over a prefilled buffer and checks it is left zeroized (R2-N3). The keys_*.rs comment and the lib.rs sentence say what is left: a one-shot's returned value is moved out of the frame that built it, the field element's limb conversion returns by value, and ec's arithmetic including a limb of the scalar in the multiplier's frames is not reached. The X9.63 bound test matches step 2's own message (R2-N1); concatkdf's step 4 wording, post-loop zeroize and multi-key doc match x963kdf's (R2-N2, N5, N9); the four untested concatkdf-* commands have hashlib-computed known answers (R2-H4); the eccdh help names concatkdf-sha256 --ikm-file and this body the concatkdf work (R2-N7). Mutants (apollo): ec (nat, barrett, montgomery, the P-256, P-521 and brainpoolP512r1 scalars, the seven extra_bits files) 476 (376 caught, 80 unviable, 17 missed, 3 timeouts): the misses are |/^ on carry bits in add, sub, add_assign, sub_assign; the documented carry-propagation shift and sign swaps in the widening multiplies, widening_mul_into included; |/^ on disjoint bit ranges in widening_square and P-521's hi[0]; and %/+ on limbs_from_be_bytes_into's shift amount, equivalent under masked shifts; the timeouts are +=/*= in the same carry loops. eccdh (the P-256 and P-521 key and agreement files) 102 (46 caught, 56 unviable, 0 missed); kdf.rs 17 more (3 caught, 6 unviable, 8 missed: x963_max_len's const-only arithmetic and derive's defensive check, as before). concatkdf lib.rs 40 (29/8/3, the pre-existing equivalents). x963kdf 35 (25/9/1, the Clone equivalent).

Round three (same day, at 10064f9: 0 Bug, 2 Hardening, 10 Notes, "ready to approve"): the pre-merge items, three commits (ec, eccdh, eccdh). Both Hardening items are what the dead-stack probe still measures end to end: keygen leaves two copies of d in its own frame (the moved-from local and the tuple temporary) and from_bytes one on the four wide curves, and every paired derivation leaves one copy of Z because the KDF's hash finalises by value (Hash::do_final_out(self), in sha2 and sha3, unchanged by this PR). The crate docs now say that a private key has no _out form, so key generation and decoding leave d where the move staged it, and name the hash's consumed state among what is not reached; the seven KDF workers' comments claim only this crate's frames, and ec's extra_bits comment speaks for its own frame (R3-H1, R3-H2). z_from_product zeroizes the buffer before its two unreachable late error exits, as its doc says (R3-N2). This body's slips: the eccdh 102 did not include kdf.rs, the SHA3-512 CLI case goes through hex only, and a round-one mutants sentence trailed the round-two paragraph (R3-N6). Left for issues, on the reviewers' grading: an in-place hash finaliser, an into form for the SEC 1 limb conversion and for key generation, the untested cleanup lines (R3-N3), and the three KDF commands' acceptance of an empty Z (R2-N4).

Not here

The Section 6 schemes and key confirmation, ECC MQV, SM2 key exchange, HKDF pairings on the other six curves (each is a marker and one impl KdfPairing in the curve's file), the X9.63 KDF over SHA-1 (not implemented in this library).

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

🤖 Generated with Claude Code

[mwcw]

Multiple reviews by Mythos, Codex and Muse

[dghgit]

Squash-merged onto release/0.1.4alpha as f60bb06 (tree identical to 55a3696). Closing by hand, as the merge happens on the private upstream. The deferred items from the review rounds and the final pass are taken on the release branch.