事前鍵は受信者がオフラインでもセッションを開始できるようにします。しかし配送経路や慎重な秘密鍵ライフサイクル管理が不要になるわけではありません。
オフラインの受信者が後から暗号化メッセージを受け取れるのは、その端末が事前に公開鍵素材を公開したからです。送信者には依然として到達可能な配送サービスが必要です。「非同期暗号化」は、通信障害を越えてメッセージが届くことや、接続されていない電話に即座に表示されることを意味しません。
耐量子設計は、鍵カプセル化メカニズムでこの考え方を拡張します。重要なのは、最初の秘密をどう確立し、古い秘密鍵をどう退役させ、後続のメッセージで安全性をどう更新するかです。
事前鍵が解決するのはタイミングの問題
Sam が新しい会話を始めたとき、Maya はオフラインだったとします。Maya の端末は以前に公開事前鍵をアップロードしていました。Sam はその素材を取得し、鍵合意の送信側の処理を実行して、最初の暗号化メッセージを送れます。Maya は再接続後、自分の端末に保持された秘密鍵を使って処理します。
つまりサーバーは公開情報を提供し、暗号化データを待ち行列に保存しますが、そこから得られるメッセージの秘密を持つ必要はありません。Signal の X3DH 仕様は、この非同期設計の一次資料です。署名付き事前鍵と一回限りの事前鍵では寿命も役割も異なります。「事前鍵」はサーバーにアップロードする秘密のパスワードではありません。
すでに確立された会話では、アプリはメッセージごとに初期設定を繰り返すのではなく、既存のセッション状態を使う場合があります。セッションの開始と、そのメッセージ鍵の更新は別の操作です。
耐量子 KEM が加えるもの
鍵カプセル化メカニズムには、鍵の生成、公開鍵を使ったカプセル化、対応する秘密鍵を使ったカプセル化解除という三つの基本操作があります。カプセル化は共有秘密と暗号文の両方を生成します。暗号文は後から届けられますが、秘密そのものは平文で送信しません。
NIST FIPS 203 は ML-KEM を標準化しています。ML-KEM-768 では、公開カプセル化鍵が 1,184 バイト、暗号文が 1,088 バイト、共有秘密が 32 バイトです。これらはアルゴリズム単位のサイズであって、メッセージパケット全体のサイズではありません。署名、従来型の鍵、識別子、トランスポートのフレーミングは追加の負荷になります。キャッシュ済みの公開鍵は、すべてのメッセージに添付されるとは限りません。
ハイブリッド構成では、プロトコルは定義された鍵スケジュールに従って従来型と耐量子の秘密素材を組み合わせます。アルゴリズム名を並べるだけでは、その組み合わせが安全だとは証明できません。ID との結び付け、検証、ドメイン分離、失敗時の処理を仕様化し、レビューする必要があります。
例としての PQXDH：万能の設計図ではない
Signal の PQXDH 仕様は、署名付きの一回限りの耐量子事前鍵と、署名付きの最終予備鍵を記述しています。送信者は提供された署名を検証して鍵合意を実行し、最初の暗号化メッセージに KEM 暗号文と鍵識別子を含めます。受信者は後から同じ秘密を導出し、メッセージを処理します。
最終予備鍵は一回限りの KEM 鍵が利用できないときの開始を支えますが、鍵が侵害された場合の分析は同じではありません。秘密鍵の削除やローテーションは以前のセッションの保護に影響します。仕様はさらに、耐量子の前方秘匿性と、能動的な量子攻撃者に対する認証を区別しています。こうした詳細を「フォールバックに安全性の代償はない」と置き換えてはいけません。
PQXDH は仕様化された一つの構成です。別の製品が文書で明示していない限り、その正確な曲線、署名、パラメータの選択を、その製品の説明にそのまま転用するべきではありません。
ラチェットと事前鍵プールは別のもの
事前鍵はセッションの確立を支えます。ラチェットプロトコルは会話中に秘密を変化させます。Double Ratchet 仕様は、メッセージ鍵の発展と、より新しい耐量子ラチェット構成を説明しています。そこには、アプリケーションメッセージごとに完全な耐量子交換を送信しない設計も含まれます。
前方秘匿性は、後で鍵が侵害されても過去のメッセージを守ることに関係します。侵害後の安全性は、攻撃者がアクセスを失い、新しい秘密素材が取り込まれた後、将来の通信の安全性を回復することに関係します。どちらも、マルウェアが電話にいつまでも残っているのに、暗号が何らかの方法でその電話の平文をマルウェアから隠すという意味ではありません。
サーバーから公開事前鍵を削除すると通常の再使用を防げますが、端末から対応する秘密鍵を削除するのと同じではありません。有用な監査は、ライフサイクル規則と遅延メッセージの扱いの両方を確認します。
Livara が文書化していることと、なお証拠が必要なこと
Livara のセキュリティページは、利用可能な場合に一回限りの鍵を用いるハイブリッドセッション確立、通常のメッセージチェーン更新、定期的な ML-KEM エポックを説明しています。これは、すべてのメッセージで完全に新しい ML-KEM 交換を行うという以前の主張とは異なります。これらは製品文書の記述であり、実装を独立して検証したものではありません。
この記述から、鍵が枯渇した際の特定のフォールバック方針、補充間隔、ネットワーク遅延の数値を推測してはいけません。これらにはリリースごとのプロトコル文書や測定結果が必要です。Proof Labも、非同期の開始、鍵の枯渇、遅延メッセージの復旧を完全に試験するものではありません。
オフラインメッセージングの主張を評価する方法
次の事例をカバーする証拠をベンダーやレビュアーに求めてください。
| 試験事例 | 観察すること |
|---|---|
| 未接続の相手への最初のメッセージ | 使用された公開鍵素材と、受信者が実際に受け取る時点 |
| 一回限りの事前鍵の枯渇 | 開始が止まるか、文書化された代替処理を行うか、明示された安全性との引き換え |
| 受信者の再インストールまたは ID 変更 | 古い待機メッセージが復号できるか、鍵の変更が見えるか |
| 遅延または順序が入れ替わったメッセージ | 保持上限、スキップされた鍵の扱い、理解しやすいエラー |
| 長期間の不在からの復帰 | 安全な鍵更新、上限のある処理、正確な配送状態 |
| 性能比較 | 端末、アプリのバージョン、ネットワーク、ペイロードサイズ、および新規開始と確立済みセッションを分けた測定 |
機密性のないテスト用アカウントとメッセージを使用します。配送テストの成功はその事例を示すだけで、すべての暗号学的性質を示すものではありません。逆に配送失敗は、暗号の破綻ではなくネットワークやライフサイクルの問題かもしれません。
よくある質問
送信時に受信者がオフラインでもよいですか？
はい。アプリに必要な公開素材と配送・保存の基盤があれば可能です。受信者は端末が待機メッセージを取得して処理できるまで、それを読めません。
KEM 鍵が大きいとチャットは必ず目に見えて遅くなりますか？
鍵のサイズだけから普遍的な所要時間の主張はできません。開始の頻度、バッチ処理、キャッシュ、実装、ネットワーク条件が影響します。負荷ゼロを約束するのではなく、ベンチマークを公開すべきです。
署名付き事前鍵はアカウントの背後にいる人を証明しますか？
それは署名 ID に対して素材を認証します。その ID と、連絡しようとしている人との結び付きは、別の信頼と検証の問題です。
耐量子暗号は接続が一切なくても動作しますか？
一部のローカル計算はオフラインで実行できます。しかしメッセージの配送には通信経路が必要であり、暗号が経路を提供するわけではありません。
