Voron 暗号/プロトコルライブラリ — レビュー依頼

これは小規模なE2EEメッセンジャープロジェクトの暗号およびメッセージングプロトコルの中核部分であり、外部レビューのために単体として切り出されたものです。これは製品全体ではありません — Androidクライアントとデプロイ設定は意図的に除外されています。ここにあるのは、レビューが必要な部分だけです。

ここに含まれるもの

• common/ — ライブラリ本体:
  • e2ee/ — X3DH-lite（非同期鍵合意）+ その上にDouble Ratchetを実装。Curve25519/ChaCha20-Poly1305/Ed25519/HKDF（JDK提供のプリミティブで構成され、この層では独自実装は一切ありません）上に構築されています。
  • crypto/ — 上記JDKプリミティブに対する薄いラッパー。
  • group/ — sender-keys方式によるグループメッセージング（初期のWhatsApp/Signalグループが採用していたMLS以前のアプローチ）。さらに、リレーがグループという概念をまったく持たないため、メンバーシップ/ロール用のクライアントサイド署名付きハッシュチェーンイベントログも含みます。
  • onion/ — リレーが接続のIPとID鍵を直接結び付けられないようにするための、オプションの層状暗号化トランスポート（固定ホップ数、サイズバケットパディング）。
  • client/, transport/, backup/ — ワイヤープロトコル、Noise_IKトランスポートハンドシェイク、暗号化バックアップ形式。
• server/ — リファレンスリレー実装:ストアアンドフォワード型ルーティング、プレキーディレクトリ、オフラインメールボックス、オニオンホップの役割。意図的に信頼を最小化しています:リレーは平文を一切見ず、配信に必要な時間を超えてメッセージを保持せず、（設計上）グループメンバーシップに関する認識をまったく持ちません。
• client/ — 統合テストでcommon/serverを相互に駆動するためのプレーンなJVMコンソールテストハーネス（実際のアプリではありません）。さらに、いくつかのスタンドアロンのエクスプロイトPoCも含みます（下記参照）。
• security-audit/ — これまでの内部レビューパスによる報告書、そこで見つかったバグ、およびすでに修正済みのバグ。何かを報告する前にこれを読んでください — 既に記載されている可能性が十分にあります。REPORT.mdが主要なものです。ADVERSARIAL_REVIEW_PAVEL.mdは、後に行われたより範囲の絞られたレビューパスです。fuzz/およびclient/.../exploit/には、説明だけでなく実行可能なPoCがあります。

脅威モデル（要約）

• リレーは信頼された主体ではありません。リレーは暗号文とディレクトリデータ（公開されたプレキー）をルーティングし、単に覗き見するだけでなく積極的に悪意があると想定されています — security-audit/内の修正済みバグのいくつかは、まさに「敵対的なリレーが何をできるか」というものです。
• 1:1セッションは、前方秘匿性（X3DH）と事後漏えいセキュリティ（その上のDHラチェット）を目指します。グループセッションはsender-keys方式です:メンバーシップが変更されるとグループ全体の鍵が再生成されますが、単一の送信者鍵が侵害されると、そのエポックのメッセージが露出します — グループ層にはメッセージごとのラチェットはありません（完全なMLS/TreeKEMではなく、意図的なスコープ削減であり、group/GroupCryptoSession.ktに文書化されています）。
• オニオンルーティングは、1ホップしか見えないリレーからIP↔IDの関連付けを隠し、フレームを固定サイズのバケットにパディングすることで、ホップ間の受動的なサイズ相関がサーキットを簡単には非匿名化できないようにします。ただし、両端を同時に監視する攻撃者に対するタイミング相関は隠しません — それにはカバートラフィック/ミキシングが必要ですが、実装されていません。これはsecurity-audit/REPORT.mdとADVERSARIAL_REVIEW_PAVEL.mdで明示的に指摘されており、隠されているものではありません。

特にチェックしてほしい点

• X3DH-lite ↔ Double Ratchet統合（common/src/main/kotlin/messenger/common/e2ee/） — これはここにある中で唯一の真正な特注暗号構成であり、その下のすべては既製品です。内部では複数回レビューされています（security-audit/参照）が、このプロジェクト外の誰かによるレビューは受けたことがありません。
• グループコントロールログの認可モデル（common/src/main/kotlin/messenger/common/group/GroupControlLog.kt） — サーバー側での強制が一切ない、クライアントサイドの署名付きハッシュチェーン。
• 上記の文書化されたタイミング相関の注意事項でカバーされていない、オニオンルーティング層のあらゆる点。

実行方法

./gradlew test

標準的なGradle/Kotlinプロジェクトで、JDK 17+が必要です。ユニットレベルのスイートには、ネットワークアクセスや実行中のサービスは不要です。security-audit/README.mdには、ライブリレーファジングとオニオン相関PoCの手順が記載されています。これらはローカルでプロセスを実行する必要があります（いかなる場合も本番ホストに向けて実行しないでください）。

これは何ではないか

これに対して独立した暗号監査は行われていません。security-audit/内のすべては内部エンジニアリングレビューです — 注意深く行われていますが自己レビューであり、形式的証明の裏付けも、その背後にある専門家/機関としての実績もありません。これを認証ではなく、レビューの出発点として扱ってください。