Background

ML-KEM-768 (introduced in #20) provides IND-CCA2 security — a strong guarantee against chosen-ciphertext attacks. However, it does not provide forward secrecy.

In our current design, each identity has a long-lived ML-KEM decapsulation key stored in a Freenet contract. Every message sent to that identity is encapsulated under the corresponding encapsulation key. If the decapsulation key is ever compromised, all past messages encrypted to that key are exposed.

This is an inherent property of static KEM schemes, and is distinct from the IND-CCA2 guarantee. It is not a bug in the current implementation — it is a known architectural property worth addressing deliberately.

Why this matters for Freenet

Freenet contracts are publicly stored and long-lived by design. An adversary can:

1. Archive all ciphertexts stored in a user's inbox contract today.
2. Wait until the user's private key is leaked (device compromise, key export, etc.).
3. Decrypt all archived messages retroactively.

The threat model is the same as "harvest now, decrypt later" — except the harvester is waiting for a key compromise rather than a cryptographic break.

What forward secrecy would look like

True forward secrecy requires ephemeral key material — each message exchange establishes a fresh shared secret that is immediately discarded. Classic examples:

• Signal protocol / Double Ratchet: combines a long-term identity key with per-session ephemeral DH, plus a symmetric ratchet for per-message keys.
• HPKE (RFC 9180): Hybrid Public Key Encryption — sender generates a fresh ephemeral KEM keypair per message; the shared secret is derived from both sender ephemeral and recipient static keys. Provides sender forward secrecy (sender can delete ephemeral key after send) but not full recipient FS.
• Post-quantum HPKE: RFC 9180 is algorithm-agnostic; ML-KEM-768 can be used as the KEM component, giving PQ-secure HPKE with sender-side FS.

Design questions to resolve

1. Is full FS achievable in a store-and-forward decentralised model? The sender may be offline when the recipient reads the message — there is no interactive handshake. HPKE-style sender-ephemeral FS is achievable; Double-Ratchet-style mutual FS is harder without a live session.
2. Key rotation policy: Even without full FS, periodic key rotation limits the window of exposure. How often should ML-KEM keypairs rotate? How is key revocation signalled in Freenet?
3. Backwards compatibility: Introducing ephemeral KEM changes the wire format and requires the sender to know which key version the recipient supports.
4. Interaction with AFT: The AFT token is tied to the recipient's inbox contract key. Key rotation may need to be coordinated with the AFT subsystem.

Suggested next step

Document a threat model section in AGENTS.md or a dedicated SECURITY.md covering:

• What guarantees ML-KEM-768 provides today (IND-CCA2, PQ-secure confidentiality)
• What it does not provide (forward secrecy, deniability)
• The preferred long-term direction (HPKE with ML-KEM, or equivalent)

A concrete design proposal for sender-ephemeral FS (HPKE-style) can follow as a separate issue once the threat model is agreed.

Related

• Epic: Replace RSA with post-quantum crypto (ML-KEM + ML-DSA) #18 — PQ crypto migration (ML-KEM introduced in Stage 2, feat(pq): stage 2 — ML-KEM-768 message encryption (#18) #20)
• NIST FIPS 203 (ML-KEM spec)
• RFC 9180 (HPKE)