Crypto-DRY feature-gaps: expose raw verify / secp256k1 tx-fields / doc_integrity-wheel / async hybrid composer / ALM layout

[emooreatx]

Feature-gaps surfaced by the cross-ecosystem crypto-DRY assessment (docs/CRYPTO_DRY_ASSESSMENT.md). These are the verify-side features downstreams had to hand-roll because verify doesn't expose them — deferred out of the v10.4.0 correctness cut because each needs API/wire design with its consumer.

1. Raw Ed25519 / P-256 verify on the FFI + wheel

The wheel exposes sign_ed25519 but no verify counterpart, so a Python consumer that signs through verify can't round-trip verification through verify (CIRISAgent audit/signing_protocol.py falls back to the cryptography library). Add ciris_verify_verify_ed25519 / ciris_verify_verify_p256 + wheel bindings. Low severity (RFC 8032 verify has ~zero drift risk) but closes the asymmetry.

2. secp256k1 tx-fields signing on the FFI (funds-moving)

ciris_verify_sign_evm_transaction takes only a pre-computed 32-byte hash, so CIRISAgent rebuilds RLP + keccak256 (with a 3-way third-party fallback: pysha3→pycryptodome→eth_hash) + EIP-155 v + EIP-55 checksum + ERC-4337 userOp hashing in Python, for real-money txs. secp256k1.rs already has keccak256 + EIP-155 internally. Expose: a tx-fields entrypoint (RLP+keccak inside the boundary), keccak256, and checksum-arbitrary-address. Medium.

3. doc_integrity on the wheel

Rust-only today, so the agent can't produce hybrid, domain-separated, version-bound verifiable-claim receipts — its DSAR deletion "proofs" use self-minted ephemeral RSA-2048 instead. Expose a produce-hybrid-signed-receipt surface on the FFI/wheel. Medium.

4. Async bound-hybrid sign/verify composer

The pqc = Sign_PQC(data ‖ ed_sig) binding rule is hand-recomposed in ~7 downstream sites (persist signing/mod.rs, edge identity.rs/capacity.rs, server lens-core ×3) — and the KMP FederationSigner.kt got it wrong (signs body, not body‖ed_sig). self_at_login::SelfSigner::sign_bound exists but is producer-shaped (returns base64 strings, no pubkeys/algo tags). Expose a general async helper that produces a full HybridSignature over ciris-keyring's async signers, so callers stop re-deriving the binding. Medium.

5. ALM §19.4 SignedRelayCapacity preimage — pick one layout

Edge's production SignedRelayCapacity and verify's holonomic::alm::signing_preimage share the domain CIRISALM-CAPv2\0\0 but have completely incompatible byte layouts (f32 vs u32 uplink, raw vs length-prefixed peer_id, edge includes stream_id/commitments). Verify's §19.4 verifier is dead against real edge traffic, and ALM is absent from the §19 cross-impl vector set (which is why it was never caught). Decide the authoritative layout (edge's v2 is the producer), regenerate verify's preimage to match or bump to CAPv3, and add the missing ALM golden to the vector set. High (domain-separation break + dead PIN-normative gate).

6. keyring seal-mints bypass the SP 800-90B latch (verify self-gap)

ciris-keyring's own mints (sealed_ed25519.rs:87, sealed_mldsa65.rs:125, usb_wrapped_mldsa65.rs, transport_identity.rs, software.rs) draw raw OsRng, so the #74 "no weak key is ever produced" invariant only holds for ciris-crypto-constructed keys, not keyring-sealed ones. Route them through ciris_crypto::random::fill. Low.

Assessment doc (this repo): docs/CRYPTO_DRY_ASSESSMENT.md → "Gaps-in-verify roadmap".

[emooreatx]

Item 6 shipped in v14.1.0 — the keyring's own key mints now honor the SP 800-90B latch. The other five items remain open.

Your framing was exactly right, and the gap was worse than "a few call sites": #74 made keygen fail-secure so "no weak key is ever produced", but ciris-keyring drew raw OsRng — so the invariant held for ciris-crypto-constructed keys and not for keyring-sealed ones, which are the federation identity keys. Inverted from where the guarantee was needed.

Routed through ciris_crypto::random::fill: the sealed Ed25519 seed, the sealed ML-DSA-65 seed, the USB-wrapped PQC seed, the transport identity, the software wrapper key, and three P-256 mints via mint_p256_signing_key — which puts the bytes through the latch rather than probing it and then drawing unchecked.

Two things that came out of doing it:

• It was structural, not incidental. ciris-crypto was an optional keyring dependency behind pqc-ml-dsa, so the default keyring build had no latch available at all. It is now a base dependency at the random feature only, which keeps the light default light.
• Reading the latch was not enough. random::fill only reads the verdict, an uninitialized latch reads as healthy, and the only production caller of run_startup_health_check was the FFI — so a direct keyring consumer could mint having never run the check. Every mint now initializes it, and an already-failed latch is decisive rather than re-run (re-running would overwrite a sticky failure, which defeats the latch).

Incidental draws are deliberately untouched: a temp-dir suffix and a TPM attestation nonce are not key material.

Proven by the fail-secure test #74 gave every ciris-crypto primitive and the keyring never had.

Still open: items 1 (raw Ed25519/P-256 verify on the wheel), 2 (secp256k1 tx-fields — funds-moving, the one I would take next), 3 (doc_integrity on the wheel), 4 (async bound-hybrid composer), 5 (ALM §19.4 preimage).