Add native HPKE encryption for nsec backups

[jmecom]

Summary

Add a Rust API that encrypts an nsec into a backup envelope using RFC 9180 Base mode: DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, and AES-256-GCM.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is d01e5f82058463709a22e93bb4cd795da5f53e10...90c01a13f51939ff22375b2885f9a6252b93f677.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 90c01a13f51939ff22375b2885f9a6252b93f677 to authorize a new review.
Any previous review applies only to its recorded range.

[jmecom]

@buzz-security-review 95f3f5c

[wpfleger96]

🤖 thanks for putting this together. The crypto looks right to me: fixed suite, a fresh context per seal, length-framed and domain-separated AAD, canonical decoding, and keeping it off the Tauri command surface. I also ran the sealing module against an independent Python/OpenSSL recipient. It passed the RFC 9180 vector first, then about 440 cases covering edge scalars, malformed and off-curve recipient keys, noncanonical envelopes, and tampering, and everything behaved. A few things inline. The main one is the plaintext copy inside the rustls seal path.

[wpfleger96]

Zeroizing here only covers our copy. rustls' aws-lc-rs Sealer::seal does Vec::from(plaintext), which allocates exactly 32 bytes. aws-lc-rs seal_in_place_append_tag then extends that buffer by the 16-byte tag before encrypting. So the realloc can move the buffer and free the original 32 bytes with the raw secret still in them, and the same thing happens on the error path. Nothing on our side can wipe that copy.

For the hidden copy, I see two options. One is to fix it upstream by pre-sizing that buffer to plaintext.len() + tag_len in the rustls sealer. The other is to use an HPKE implementation that seals in place into a caller-owned buffer. Either way, I'd pass secret_key.as_secret_bytes() straight through here. SecretKey already erases its own storage on drop, so the extra to_secret_bytes() + Zeroizing copy isn't buying anything. I'd also reword the doc comment above: "copies only its raw 32-byte secret representation into a zeroizing plaintext buffer" reads like the secret never lands anywhere unwiped.

[wpfleger96]

This pair doesn't actually depend on the framing. a|bc vs ab|c differ even with bare concatenation, so the test still passes if push_framed becomes extend_from_slice. The pair that collides without length prefixes is ("ab", "c") vs ("a", "bc"). The fixture's aad_hex does pin the framing, so it's covered, just not by the test named for it.

[wpfleger96]

The ["ncrypt", "sec1"].concat() looks like it's there to get past the NIP-49 allowlist scan in egress_guard_tests.rs. This module never touches the NIP-49 codec, so I'd just drop these two lines instead of routing around the guard.

[wpfleger96]

nit: every other failure in decode_canonical_base64 returns InvalidField { field, .. }, but malformed base64 goes through InvalidEnvelope and drops the field name. InvalidField { field, reason: "invalid base64url" } would be consistent. Relatedly, the InvalidField doc says "trusted-enrollment field", but the variant is also used for enc and ciphertext.

[wpfleger96]

nit: I think the pub here is just keeping dead_code quiet until there's a caller. The in-tree pattern for that is #[cfg_attr(not(test), allow(dead_code))] mod ... (see terminal_transport further down), which keeps this off buzz_lib's public surface.

[wpfleger96]

I re-reviewed 2cd08b1b7bd82ce43d4f41664216d5211f525237. The framing test now covers actual concatenation collisions at both field boundaries, and the comments accurately describe the zeroization limitation. No new blocking findings.

We’re explicitly accepting the documented provider-memory risk for this unintegrated part-1 PR. The hidden plaintext copy is not fixed; this approval records that risk acceptance rather than treating the comment as a fix. The remaining cleanup suggestions are non-blocking.

This follow-up was source review only; I did not rerun tests on this revision.

[bradseiler]

🤖 Reviewed exact head 90c01a13f51939ff22375b2885f9a6252b93f677 for cryptographic correctness, wire canonicalization/interoperability, secret handling, and API misuse hazards. No blocking findings. The fixed RFC 9180 suite IDs and big-endian encoding are correct; metadata is domain-separated and length-framed in AAD; recipient keys are structurally constrained with curve validation delegated to the HPKE provider; envelope decoding enforces canonical UUID/pubkey/base64url forms; Base mode sender-auth limitations and the provider plaintext-copy limitation are documented; and the API remains native-only rather than renderer-callable.

Non-blocking follow-ups: before treating v1 as a frozen multi-platform protocol, add a reciprocal external test proving the intended Kotlin/service receiver opens a Rust-produced vector; when this dormant primitive is integrated, add tests enforcing identity-mutation serialization, live-key acquisition, and authenticated enrollment/pubkey binding.

Independent exact-head validation reported: git diff --check origin/main...HEAD passed; all 13 hpke_key_backup::tests passed; and a final full just desktop-tauri-test rerun passed. CI has no pending or failing checks. GitHub still reports BLOCKED / REVIEW_REQUIRED, and the exact-head Codex security-review comment says a new review is required for the current range.