ADR-037: E2E encryption security review + design/implementation docs (E2E_ENCRYPTION.md)

[cuttlefisch]

Part of #131. A cryptographic-soundness gut-check + proper documentation of the E2E design, grounded in prior art, validating N-peer P2P scaling.

Deliverables

• Design-level review (before more 3b code): multi-lens adversarial crypto review →
  docs/E2E_ENCRYPTION.md v1 + findings list.
• Implementation-level review (after 3b/3c land, before 3d's confidentiality gate): verify the code
  matches the reviewed design.

Lenses (each grounded in primary-source prior art)

1. AEAD usage — XChaCha20-Poly1305, 24-byte random nonce collision-resistance, key sizes, AAD/binding.
2. Key wrap — sealed box (ephemeral X25519 ECDH → SHA-256 KDF → AEAD), Ed25519→X25519 birational map, KDF domain-sep + pubkey binding.
3. encrypt-then-sign ordering / verify-before-decrypt (ADR-036/037).
4. Key distribution + trust — genesis anchor, latest-owner-wrap-wins, signed-op-log integrity, forge/inject resistance.
5. Removal/rotation §D3 — forward exclusion; explicit absence of FS/PCS (one symmetric key per KB until rotation).
6. Metadata leakage to the key-blind daemon — ciphertext, op-ids (=SHA-256 of ciphertext), epoch client-ids, counts, timing.
7. N-peer P2P scaling — O(N) sealed-box wraps per enable/rotation, op-set YMap merge at N, membership-DAG cost, rekey-on-churn.

Prior-art benchmark

MLS/TreeKEM (RFC 9420), Signal Sender Keys, Matrix Megolm, Keyhive/BeeKEM (Ink & Switch, ADR-037 §D4), CRDT-E2E (Jazz, Y-Sweet). Position our "single per-KB symmetric content key, sealed-box-wrapped to each member, distributed via the signed membership log, rotated on removal" honestly; confirm v1 (Sender-Keys-style, no FS/PCS) is a sound documented starting point with TreeKEM/BeeKEM as the named next step.

Outcome

Real bugs block the relevant PR (3b/3c); design limitations documented (not silently shipped). docs/E2E_ENCRYPTION.md: threat model, primitives, key lifecycle, what-is/isn't-protected, scaling analysis, prior-art table, findings.

[cuttlefisch]

Design-pass review complete — verdict + findings

Verdict: the core crypto is sound (no must-fix break inside the primitives). MAE v1 ≈ Jazz/cojson, more efficient than Signal Sender Keys (O(N) vs O(N²) on removal), avoids Megolm's homeserver-trust mistakes; BeeKEM is correctly named as the FS/PCS + O(log N) next step (ADR-037 §D4). Full write-up: docs/E2E_ENCRYPTION.md.

Findings (disposition):

#	Finding	Sev	Disposition
F1	Anchor TOFU — derive_kb_content_key re-derives anchor from relay-supplied collection vs pinning to OOB-verified owner	WEAKNESS→BUG	3b: cross-check genesis author == authenticated owner; mesh node-id pinning follow-up
F2	Encryption mode is an unsigned flag → relay can downgrade e2e→none → plaintext	WEAKNESS→BUG	3b: assert E2e in the signed op-log; seal fail-closed
F3	Owner key-gen/wrap/rotate not wired (design+tests only)	BUG(gap)	= 3b/3c (the WIP)
F4	Content-key authority undefined under Quorum governance (frozen key)	WEAKNESS	3b: restrict E2e to SingleOwner
F5	Node titles cleartext in manifest on E2e KB	WEAKNESS	Document + omit/encrypt — follow-up
F6	No all-zero/low-order DH rejection in wrap/unwrap	WEAKNESS	3b (cheap)
F7	No AAD binding + no content-key-id in signed header	WEAKNESS(def-in-depth)	Follow-up
F8	Op-set + membership-log unbounded growth; O(ops) derivation	WEAKNESS(scale)	Document — ADR-028 follow-up
F9	ContentKey zeroize best-effort	LIMITATION	Follow-up

F1/F2/F4/F6 fold into #151 (3b). F5/F7/F8/F9 + mesh-pinning → hardening tracker. Implementation pass re-runs after 3b/3c.

[cuttlefisch]

Deliverables shipped — closing.

Design-level review + docs (via #159):

• docs/E2E_ENCRYPTION.md — content-encryption primitives, threat model, key lifecycle, what-is/isn't-protected, scaling, prior-art table (MLS/TreeKEM, Signal Sender Keys, Megolm, Keyhive/BeeKEM).
• docs/SECURITY_REVIEW.md — identity + authorization deep review (SSH-style asymmetric trust + capability/ReBAC hybrid), every finding file:line + prior-art-grounded. Verdict: no auth-bypass / no priv-esc in the membership layer.
• docs/KB_SHARING.md — holistic end-to-end reference. ADR-038 (editor-authored membership) + ADR-039 (identity/authz hardening).

Implementation-level review (the pass before the 3d confidentiality gate): the two HIGH findings shared one root cause and landed in #157/#163 (unified op-log epoch fence on every write path — A1 epoch-source asymmetry + N1 mesh-dialer fence gap). The 3d + §D3 CI gate that this review was meant to make meaningful is now live.

Residual findings are tracked as scoped issues (design limitations documented, not silently shipped):

• A2 local blocklist (a missing feature, not a live bypass) → ADR-039 A2: implement the local blocklist (self-protection deny-list) end-to-end #162
• Identity hardening I1–I6 (single-key separation, rotation/rebind, at-rest, Windows perms) → ADR-017/037: identity hardening — key rotation/rebind, single-key separation, at-rest, Windows perms (I1-I6) #158
• Post-3b hardening (manifest titles, AAD, zeroize, compaction, mesh anchor pinning) → ADR-037 E2E hardening follow-ups (post-3b): manifest titles, AAD, compaction, zeroize, mesh anchor pinning #156

v1 (single per-KB symmetric key, sealed-box-wrapped per member via the signed membership log, rotated on removal) is positioned honestly as a sound Sender-Keys-style starting point with TreeKEM/BeeKEM as the named next step.