メッセージごとのチェーン進行と耐量子エポックの更新は、ラチェットの異なる課題を解決します。
ハイブリッド耐量子ラチェットは、従来型と耐量子の両方の材料を使ってメッセージ鍵を更新します。その狙いは、慎重に定義された前提のもとで、一方の構成要素が脆弱になっても保護を維持しつつ、特定の鍵の侵害が時間の経過とともにもたらす被害を限定することです。
Livara は、P-256 と ML-KEM-768 を使用する LVR1 について、この方式を文書化しています。設計を理解するには、初期の鍵確立、通常のメッセージチェーン更新、定期的な耐量子リフレッシュを区別する必要があります。これらは、すべてのメッセージで実行する同一の操作ではありません。
共有秘密から変化するメッセージ鍵へ
鍵確立の仕組みは、鍵スケジュールに利用できる秘密材料を参加者に提供します。その後、ラチェットプロトコルは状態を進めてメッセージ鍵を導出します。会話全体で同じ内容暗号鍵を維持するわけではありません。
NIST FIPS 203 は、ML-KEM-768 パラメーターセットを含む ML-KEM を規定しています。これが確立するのは共有秘密であり、メッセージのペイロードは AES-GCM などの認証付き暗号が暗号化します。認証と構成要素の組み合わせ方は、より広いプロトコルの領域です。
Livara のセキュリティ概要は、ハイブリッド鍵確立、互いに独立した従来型ルートと耐量子ルート、メッセージに伴って進む一方向の送受信チェーン、定期的な ML-KEM エポック更新を説明しています。そこでは、内容とヘッダーを保護する前に、メッセージ鍵を現在の耐量子ルートと組み合わせるとしています。
この説明を「各メッセージで新しい P-256 交換と新しい ML-KEM カプセル化が行われる」と言い換えてはいけません。チェーンの進行は、比較的低コストな鍵導出のステップであり得ます。
エポックによって何が変わるのか
エポックとは、特定のリフレッシュに対応するプロトコル状態の期間です。大きな鍵確立メッセージをエポックに分散して送ることで、繰り返し生じる通信負荷を減らせますが、その分、更新規則は安全性に関わるものになります。
レビュー担当者は次の点を確認すべきです。
- 新しいエポックを起動するのは、カウンター、時間、相手の操作、それとも別の条件でしょうか。
- エポック識別子と鍵材料はどのように認証されますか。
- 遅延、重複、順序の入れ替わったメッセージはどうなりますか。
- 更新が欠けている場合や、古くて互換性のない相手に対して、クライアントはどう対応しますか。
- 遅延配信のためにどの古い秘密を保持し、いつ破棄しますか。
実装には正確な答えが必要です。「定期的」という言葉だけでは、完全な復旧仕様や相互運用仕様にはなりません。
ベンチマークを作り上げずにプリミティブのサイズを定量化する
FIPS 203 における ML-KEM-768 のカプセル化鍵は 1,184 バイト、暗号文は 1,088 バイトです。これはプリミティブの符号化サイズであり、Livara のメッセージやハンドシェイク全体のサイズではありません。実際の通信量は、プロトコルヘッダー、署名、フレーミング、各値の送信頻度によって決まります。
P-256 鍵のサイズも表現形式に依存します。例えば、圧縮された曲線上の点と非圧縮の点では、符号化後の長さが異なります。形式の表示がない「P-256 鍵サイズ」を ML-KEM 暗号文と比較しても、完全な帯域幅分析にはなりません。
ラチェットのコストを評価するには、代表的な端末で会話ごと・エポックごとのバイト数、CPU 時間、メモリ、無線部の起動回数、エンドツーエンド遅延を測定します。ビルドとネットワークの条件も報告します。こうした測定なしに、「バッテリーへの影響は無視できる」とも、あらゆる環境で実行時間が 1 ミリ秒未満だとも正当化できません。
前方秘匿性と侵害後の回復
前方秘匿性は、所定の古い秘密が消去されていることを前提に、後の特定の秘密が露出しても過去のメッセージを保護することを目指します。侵害後の安全性とは、攻撃者が端点を支配しなくなり、攻撃者に未知の新しい秘密材料がプロトコルへ入った後、保護を取り戻すことに関わります。
Double Ratchet 仕様は、この区別と侵入後の回復の限界を説明しています。マルウェアによる継続的なアクセス、操作された乱数、関連する交換を制御する能動的な攻撃者は、期待される回復を妨げ得ます。もう一通メッセージを送っただけでは、盗まれたセッションの失効や、侵害されたスマートフォンの無害化は証明されません。
ハイブリッド構成にも、適切な認証と組み合わせが必要です。「攻撃者は両方のアルゴリズムを破らなければならない」というのは、その構成の前提に基づく意図された性質であり、実装バグや悪意ある端点まで含む無条件の主張ではありません。
機能ごとの境界を明確にする
Livara の文書では、LGS1 グループ送信者鍵は一対一の LVR1 セッションを通じて配布されます。だからといって、グループ送信者チェーンが直接チャットのダブルラチェットと構造的に同じだということにはなりません。現在のセキュリティページでは、古くて互換性のないグループを E2EE の対象外とし、新しい暗号化グループを作る前にメンバーの準備が整っていることを要求しています。
添付ファイルには固有の内容暗号鍵があり、保護された会話の中で運ばれます。通話と任意のサーバー録音は別途レビューが必要です。シグナリング経路がハイブリッドセッションを使うという理由だけで、メディアに耐量子保護があると推測してはいけません。公開チャンネルと運用メタデータは、非公開コンテンツの機密性の範囲外です。
信頼を高めるものは何か
バージョン管理された仕様、相互運用性と失敗ケースのテスト、独立したレビュー、レビュー済みソースと配布クライアントの明確な関係を探しましょう。標準アルゴリズムは構成要素についての有用な証拠ですが、その組み合わせの認証ではありません。
Livara の Proof Lab は選択された従来型プリミティブを実演し、LVR1/LGS1 の完全な組み合わせをそのローカルベンチから明確に除外しています。脅威モデルも引き続き必要な背景情報です。これらの資料は問いを整理するのに役立ちますが、完全なプロトコルおよび実装の評価に代わるものとして示すべきではありません。
