Group crypto: decision memo - MLS vs DCGKA vs Keyhive/BeeKEM for E2E sync and sharing

[lannbot]

Deliverable: a decision memo selecting the group-keying approach for E2E sync and sharing. See NOTES.md — Group crypto.

The structural problem: MLS (RFC 9420) assumes a delivery service imposing linear order on group-changing commits; concurrent commits fork the group. This system is partition-tolerant P2P — concurrency is the normal case — so raw MLS fights the architecture.

Candidates:

• MLS + an ordering layer over gossip/relay (fights the grain; membership changes need connectivity to a sequencer).
• DCGKA — Weidner/Kleppmann et al., Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees: group keying designed for causal broadcast and concurrent membership changes.
• Keyhive / BeeKEM (Ink & Switch): capability auth + concurrency-tolerant group keying purpose-built for automerge sync. Closest-fit prior art; at minimum steal the decomposition, possibly track as a dependency.

CRDT-specific criteria beyond the usual FS/PCS checklists:

• History handoff: what a new member/device receives (full history vs snapshot) is a policy knob that sets the read-back window.
• PCS on a sync workload is weaker in practice: history persists; recovery from compromise includes re-encrypting the past — a rotation job, not a ratchet step.
• Implementation maturity and wasm-portability (must run in-guest or over polymorph:webcrypto's surface).

Also in scope: whether device-group (one user) and sharing-group (many users) use one mechanism — the unification leaning from the identity issue assumes yes.

[lannbot]

Investigation: Keyhive as the group-crypto/access-control candidate (2026-08-16)

Findings from a code + design-doc review of inkandswitch/keyhive at main (pushed 2026-08-15), the lab notebook through entry 06 (2026-07-31), and the sibling inkandswitch/subduction. Recorded as findings, not a ruling.

What Keyhive is now (vs. the notebook)

Three layers, matching our problem decomposition almost exactly:

1. Convergent capabilities — a CRDT-flavored capability graph: every agent is a public key; documents/groups/users/devices are all "groups" (some stateless); delegation is transitive and attenuable; revocation is an op in the same partial order. Access tiers: pull / read / mutate / manage — "pull" (may fetch ciphertext, cannot decrypt) is a tier our design discussion didn't name, and it slots directly into the nothing-live-is-trusted invariant: it is exactly what an untrusted relay/storage peer checks.
2. Group management CRDT — membership ops form a hash-linked partial order; concurrent admin revocations resolved by seniority rules; re-adds must causally succeed the revocation they undo; auth ops can pin doc_heads to order themselves after content.
3. E2EE with causal keys + BeeKEM CGKA — per-document group keys via BeeKEM (concurrency-tolerant TreeKEM variant: concurrent updates keep "conflict keys" at overlapping nodes, resolved by causally-later updates; membership changes blank paths). Content encrypted in compressed chunks; each chunk's key bundle includes keys of causal predecessors.

Workspace reorganization since the March 2025 pre-alpha: Beelay (sync) was removed from the keyhive workspace (PR #151) and the sync layer now lives in subduction (sedimentree history sharding + RIBLT set reconciliation, transport-pluggable with first-party subduction_iroh on iroh 1.0, WebSocket, HTTP long-poll; subduction_keyhive is the auth-policy bridge; first-party automerge ingest crates). Keyhive proper is now: keyhive_core, beekem (extracted CGKA), keyhive_crypto, keyhive_wasm. Published to crates.io (keyhive_core 0.5.0, keyhive_crypto 0.2.1, beekem 0.3.0).

Security-property set (what we'd actually be buying)

• Forward secrecy: none, by explicit design. Causal-key encryption means a chunk key discloses predecessor keys; the implementation retains old individual secrets unboundedly (κ=∞ in the formal analysis's terms). This matches the position already in NOTES.md ("history handoff is a policy knob"; "PCS weaker in practice") — Keyhive made the same call and wrote it down.
• PCS: yes — leaf key rotation ratchets the group secret forward.
• Cross-fork security: yes — a notion novel to the decentralized setting (compromise on one concurrency branch must not break sibling branches); prior decentralized schemes (Causal TreeKEM, DCGKA per the analysis) are vulnerable. Formalized in a paper linked from notebook entry 06 (eprint 2026/1434, D. Yen et al.).
• Formal analysis is fresh and actively reshaping the protocol: PR #213 (merged 2026-08-15, the day before this review) replaced BeeKEM's path-secret ratcheting with independently sampled secrets because inner-node compromise gave access to ancestor nodes. The team responds to analysis quickly — and the protocol is still moving at the crypto-design level.
• Bespoke pieces needing review before we rely on them: the content-encryption envelope (XChaCha20-Poly1305 with a synthetic nonce/key-commitment scheme via keyed BLAKE3 — their own design doc carries a CAUTION flag); design/threat_model.md is an empty stub; zeroization audit is an open issue (#187); no external security audit; README still says pre-alpha / DO NOT USE.

Fit with the polymorph stack (unusually good)

• Identity seam already matches. keyhive_core is generic over AsyncSigner<F: FutureForm> (Local vs Sendable future forms for single-threaded wasm vs native), and keyhive_wasm already ships a WebCrypto signer holding a non-extractable platform Ed25519 key. That is precisely component-iroh's crypto split (identity via polymorph:webcrypto handle; bulk crypto in-guest). An AsyncSigner over the polymorph:webcrypto ed25519-sign surface is a direct translation.
• Compiles for wasm32-wasip2 today: cargo check -p keyhive_core --target wasm32-wasip2 passes clean (keyhive_core + beekem + keyhive_crypto), rustc 1.96. No tokio in the core dependency tree (dev-only); stores (CiphertextStore) and event emission (MembershipListener) are traits — the shape is component-friendly. We would bypass keyhive_wasm (wasm-bindgen/JS-glue) entirely and wrap keyhive_core in a component behind our own WIT.
• Cipher suite is wasm-friendly and timing-class-aligned: dalek Ed25519/X25519, XChaCha20-Poly1305, BLAKE3 — the ChaCha family is exactly what the polymorph-tls wasm timing profile prefers in-guest. BeeKEM's DH path secrets must live in guest memory (the tree derives public keys from secrets), so non-extractable platform keys can't serve the CGKA inner nodes — same class-B posture as component-iroh's key-exchange split, no surprise.
• The model diagram is our model. design/group_membership.md's device-management example: "Alice" is a Keyhive group over laptop/tablet/phone leaves, documents delegate to groups, and per-app WebCrypto contexts appear as attenuated sub-leaves ("Homework App context: only Homework doc"; "Notifications App: only LaTeX doc, read"). Devices-as-leaves, user-as-group, apps-as-attenuated-principals — NOTES.md §Identity and §Permission model, drawn by someone else first.
• Identity antigoal is our layering. Keyhive deliberately excludes human-identity binding (naming, discovery, verification) — our sigchain/petname/contact-exchange layer (Identity: devices as leaves, user as signed device list; enrollment ceremony; contact exchange and verification #10, Addressing and discovery: contact exchange with a static-only origin; the user@host question; per-user published content #14) sits above it without conflict.
• Sync: subduction's transport trait + first-party iroh transport means a component-iroh transport is a natural seam, and sedimentree solves encrypted-chunk sync (server diffs ciphertext without decrypting) — a problem we'd otherwise design from scratch. Subduction is also marked "very unstable API / DO NOT USE"; watch, don't build on yet.

Instability evidence (calibration for the co-evolution decision)

• Protocol-level crypto change merged the day before this review (#213).
• ~58 alpha releases of the wasm package; workspace at 0.0.0-alpha.3; API-churn PRs ongoing (access-level API #209, E2EE application-secret chains #208, transitive delegation/revocation only landed 2026-05 in #195).
• Sync layer moved repos entirely (beelay → subduction) within the last year.
• Three core contributors (Zelenka, Mumm, Good); Ink & Switch lab funding model — projects can wind down into essays.
• Open issues include semantic bugs in membership (#136, #137) and an unresolved design question, "Dynamic membership in absence of finality" (Safari floor: a future JSPI + multi-memory release #127).

Recommendation

Adopt the decomposition now; adopt the code behind a seam; do not adopt the wire/storage formats as stable.

1. Design alignment (free, immediate). Import Keyhive's vocabulary into our design where it's convergent: the pull/read/mutate/manage tiers (pull-access is the missing name for our untrusted-relay tier), doc-as-ACL-unit, devices/users/apps as one principal kind. Update the Group crypto: decision memo - MLS vs DCGKA vs Keyhive/BeeKEM for E2E sync and sharing #9 leaning: Keyhive primary candidate; DCGKA fallback; raw MLS effectively eliminated (its sequencing assumption remains disqualifying, and BeeKEM now has the analysis DCGKA-era designs lacked for the cross-fork case).
2. Spike behind our own WIT (the real test). An experiments/-style spike: keyhive_core in a wasm32-wasip2 component; AsyncSigner over polymorph:webcrypto ed25519-sign; two component instances exchanging membership/CGKA events over component-iroh streams; measure boundary costs and API fit. Wrap in a polymorph:groups-shaped WIT surface from day one so the implementation stays swappable (DCGKA as the named fallback if Keyhive stalls).
3. Co-evolution posture. Pin by exact version/rev; absorb protocol-breaking changes deliberately (changes like #213 alter what ciphertexts/trees mean — upgrading is a migration, not a bump). Track the repo + the keyhive-beelay Discord channel. Expect to contribute (wasip2/component packaging, timing-class review of the in-guest paths — the polymorph specialty); upstream filings are their own decision each time.
4. Guardrails. Treat FS-absence and the causal-key read-back window as recorded properties in our threat model (Threat model: the adversary table and the "nothing is both live and trusted" invariant #1). The bespoke nonce/commitment envelope gets independent review before any polymorph data ships under it. Nothing user-facing depends on Keyhive stabilization for v1 scheduling — the WIT surface is designed against our requirements (Permission model: linking as enforcement - deny-by-unlink, prompt-on-first-use, revocation semantics, durable grants #6, Data services: the polymorph:automerge surface - document as ACL unit, host-side ownership, indexing, encrypted backup #8) and validated by the spike, not blocked on upstream.

References: lab notebook · design/ (group_membership.md, ciphersuite.md, causal_encryption.md, sedimentree.md) · BeeKEM analysis · subduction · PR #213, #151 (Beelay removal).

[lannbot]

Provisional plan recorded in NOTES.md §Provisional plan (commit d3e13d2): Keyhive primary, DCGKA named fallback, raw MLS eliminated. keyhive_core behind a polymorph:groups-shaped WIT; identity via AsyncSigner over polymorph:webcrypto. @unstable until the conversion checkpoints: embeddability spike, polymorph-test convergence gates, scaling vs our doc-count profile. This issue's deliverable shifts from open-ended decision memo to validating the provisional choice (or triggering the fallback).

[lannbot]

Correction to the note above (mechanism, not plan): no @unstable gates — the entire framework is unstable until declared otherwise, so per-surface stability annotations state nothing. The conversion checkpoints stand unchanged. Recorded in NOTES.md status note, commit a92b12b.

[lannbot]

Refinement from design discussion (NOTES.md §Provisional plan updated, commit 61fb323): a separate keyhive implementation/deployment is not useful under subduction adoption — but the polymorph:groups surface is necessary regardless. Verified: subduction_keyhive::SubductionKeyhive is an in-process wrapper holding the Keyhive instance (implements subduction ConnectionPolicy/StoragePolicy against it, carries membership-op sync). So: one keyhive instance, inside the engine composite with subduction; groups and sync as separate WIT exports of that composite. Spike (1) stays but scoped to facts-validation (signer-over-webcrypto, wasip2 embedding, persistence, op semantics) over a throwaway channel — it must not grow its own sync protocol. Failure asymmetry now named: dropping subduction leaves groups untouched; dropping keyhive drops the bridge too, so the DCGKA fallback includes rebuilding op-sync + policy enforcement. Cross-ref #8.

[lannbot]

Spike (1) executed and passed (commit dc56a30, spikes/keyhive/).

keyhive_core + beekem + keyhive_crypto at pinned upstream main (post-#213, rev efe6ccf) run unpatched as a wasm32-wasip2 component. Identity signing routes through polymorph:webcrypto via the AsyncSigner<Local> seam — non-extractable platform handle, secret never in guest memory, no executor shims. A wasmtime host instantiates the component twice (Alice, Bob) and shuttles opaque blobs; no sync protocol, per the scoping rule.

Asserted end to end: contact-card exchange → doc + add_member(Read) → 3.0 KB of membership events ingest with zero stuck → cross-instance encrypt/decrypt → revoke → re-encrypt → decrypt refused with KeyNotFound under adversarial full delivery (Bob holds every op incl. the rotation; exclusion is BeeKEM key derivation, not delivery policy) → history stays readable post-revocation (the recorded no-FS/causal-keys trade, now observed) → archive (12 KB) → restore with the same platform-held signer → revocation survives the round-trip.

Measured (indicative): every step sub-millisecond in a native host; 17 signature calls across the WIT boundary for the whole owner-side scenario (per-op, not per-byte — browser crypto.subtle latency stays negligible at op rate); 194-byte ciphertext envelope on an 18-byte plaintext (amortized by chunking in real use).

Finding routed to #11: try_from_archive requires the same signer, so durable browser-side keyhive state depends on platform key persistence (webcrypto keystore direction — CryptoKey structured-clone into IndexedDB); upstream's own wasm binding silently falls back to an in-memory signer, which we would not accept.

Checkpoint status: embeddability converted for the keyhive half. Remaining for #9/#8 conversion: the subduction spike (2) with a polymorph:iroh Transport, the walking skeleton (3), a browser/deltic leg of this same component against real crypto.subtle, convergence/partition gates in polymorph-test, and scaling vs our doc-count profile.

[lannbot]

Walking-skeleton phase 3a result relevant to this issue (details on #8, commit e9ffffa): the one-identity unification runs — a single non-extractable webcrypto key backs keyhive's AsyncSigner and subduction's Signer with the same 32-byte id on both layers, the devices-as-leaves substrate working end to end. And a keyhive-semantics finding for the data-layer rules: a BeeKEM add is not retroactive — epoch membership at seal time determines readability, so "create → add members → first seal" is the required flow, and late-joiner history access goes through causal keys via post-join chunks (the history-handoff knob, now concrete).