[freeze] X25519 key exchange + sealed-box encryption (KeyPair API shape is cheaper to settle pre-1.0)

[joeldsouzax]

Problem

The crypto module signs and verifies but cannot encrypt: X25519/X448 key exchange and sealed-box encryption are unbuilt (tracked as Agency Roadmap #6; called out in agency's keri-gap-analysis.org). Downstream needs are real, not hypothetical: IPEX credential exchange (Agency #38/#62/#63) and any private agent-to-agent payload over Zenoh need asymmetric encryption to the recipient's keys, and KERI's convention (keripy parity) derives the encryption key from the existing Ed25519 material.

Why this is a freeze card

It's additive code, but it touches frozen-adjacent surface: KeyPair<A>'s algorithm-parameter design, the zeroization pattern, and the Matter code coverage for X25519/X448 public keys, private keys, and cipher variants (the codes exist in the table; the operations don't). Shaping KeyPair to accommodate an encryption algorithm family is much cheaper before 1.0 pins its API.

Work

• X25519: Ed25519→X25519 conversion (keripy-compatible derivation), ECDH, sealed box (crypto_box-style: ephemeral key + XSalsa20/ChaCha20-Poly1305 — match keripy's libsodium semantics exactly, differential-test it)
• Sealed-box encrypt-to-Verfer / decrypt-with-KeyPair API, private material in Zeroizing per existing convention
• Matter round-trip tests for the cipher/key codes now exercised
• X448: assess whether keripy actually exercises it; if not, stub-with-rationale rather than build (record in P3.1 · Evaluate deferred major crypto bumps #34's crypto-currency review)
• no_std/wasm32 story for the chosen RustCrypto crates (x25519-dalek + crypto_box are no_std-capable — verify in the flake check matrix)

Acceptance

Seal/unseal round-trip differential-tested against keripy/libsodium vectors; feature-gated like the rest of crypto; no_std build stays green.

From the 2026-07-05 cross-repo roadmap review (ROADMAP.md Phase 5: IPEX/ACDC track). Supersedes the cesr half of Agency Roadmap #6.