# E2E 暗号化の現状まとめ

## できていること（merged 済み、フローが繋がる範囲）

- **暗号方式の基盤**: per-group X25519 keypair を `HKDF(master_seed, "kneume.x25519.group:" + group_id)` で導出。age v1 envelope で複数 recipient に暗号化。
- **server 側のデータモデル**: `GroupEncryptionEnabled` event、`groups_current.encryption_enabled` フラグ、`group_members.member_pubkey`（同一 (group, did) で COALESCE 更新）、`posts_current.encrypted` / `encrypted_payload`、`add_group_member(pubkey=…)`。`enable_group_encryption` は creator-only / g_public 不可 / 不可逆 / idempotent。
- **MCP gateway proxy (`kneume-channel bridge --proxy`)** が `.mcp.json` の入口に。`run_sql` の結果を per-row で復号、`create_post` / `update_post` の args を encrypt して `encrypted_payload` 化、`create_group` 直後に creator の per-group pubkey を `add_group_member` で自動 announce。暗号化 group に recipient 0 件で書こうとしたら hard error。
- **master_seed 供給経路**: SPA `/pair` で乱数 32B 生成（または控えを貼り付け）→ loopback POST → CLI(`kneume-channel pair`) が tmpfs($XDG_RUNTIME_DIR) 0600 / 8h の session cache に保存 → proxy 起動時に読む。loopback サーバは CORS preflight 対応済み (#201)。
- **env stub の撤去**: `KNEUME_DEV_MASTER_SEED` が #219 で削除予定（PR 出し済み）。マージされれば seed の入手経路は本物のフローだけに。
- **実機の往復**: pair が手元で実際に通ったところまで確認済み。

## まだできていないこと

**本筋として未着手:**
- **SPA 側の復号 (focal #7)**: 今は AI(MCP 経路) で proxy が復号している。ブラウザ単体で kneume を直接読み書きするには SPA 自身が seed を持って age 復号・暗号する必要がある（ブラウザ単体運用が前提と確認した部分）。SPA に seed を保持する仕組み（IndexedDB / sessionStorage / メモリ内）も含めて未実装。**残作業として一番大きい**。
- **multi-user で他人を招待する SPA UI**: `add_group_member` は MCP にあるが、ブラウザから他ユーザーを暗号化グループに招待する UI フローは未整備。

**保留中（意図的に後回し、決定済み）:**
- **同一 DID に複数 pubkey を許すスキーマ拡張**: 鍵ローテーション／複数 device passkey に必要。今は (group_id, member_did) で 1 pubkey 上書き。**将来 passkey に移るときに拡張**で合意済み。
- **lazy auto-trigger of pairing**: 設計 §5 にあった「暗号化要求 call が来たら自動でブラウザ起動して pair」は未実装。当面は明示 `kneume-channel pair` で運用する決定。
- **passkey PRF 経路**: Bitwarden / Firefox-Linux のエコシステム制約で断念。乱数 seed に倒し、将来は鍵ローテーションで移行する設計。
- **過去 plaintext post の migration**: g_public は永久 plaintext、private group は現状 0 件、ということで focal #4 で「対応不要」決定済み。

**未検証:**
- pair 自体は通ったが、**実際に暗号化グループに post を作って → 別 session で復号して読む**、までの end-to-end 動作は未確認。次に触るときに一回試走しておくと安心。
- session cache の 8h expire 後の UX（pair やり直しの導線）も本番運用していくと気になる箇所。

次の自然な一歩は、たぶん **(a) end-to-end の一回試走** → **(b) SPA 側 age 復号 (focal #7)** という順かな、と。