送信者鍵を使うグループメッセージングでは、通常のメッセージごとに、受信者全員向けのコピーを個別に暗号化せずに済む場合があります。送信者は安全な一対一のチャネルで鍵素材を配布し、その後は送信者チェーンをグループメッセージに使います。これにより送信者の重複するアップロード処理を減らせますが、メッセージを届ける総コストがグループの規模に依存しなくなるわけではありません。
帯域幅に関する主張を比較する前に、通常メッセージのアップロード、鍵の配布、サーバーによる配信を区別しましょう。
一つの「グループメッセージ」に隠れた三つのコスト
N 人のメンバーを持つ単純化したグループを考えます。これは説明用のモデルであり、Livara の実測ベンチマークではありません。
| 処理 | 一対一のメッセージコピー | 送信者鍵方式 |
|---|---|---|
| 送信者が通常の内容をアップロードする | 受信者ごとに暗号化した別々のコピーが必要になり得る | 初期設定後は一つのグループ暗号文をアップロードできる |
| 鍵の確立または配布 | 一対一のセッションを確立し維持する必要がある | 送信者の鍵素材を認可された受信者に届ける必要がある |
| 中継サーバーがグループに配信する | 受信者は依然として各自のコピーを必要とする | 受信者は依然として各自のコピーを必要とする |
| メンバーが変わる | セッションとアクセス方針を更新する必要がある | 新しい送信者の鍵素材を再配布する必要が生じ得る |
「送信者のアップロード量が一定」という説明は、このモデルの一部分を指します。ネットワーク通信量全体が一定であること、メンバー変更のコストがゼロであること、どのデバイスでも同じ性能であることを意味しません。
IETF の MLS 仕様 RFC 9420 は、送信者鍵の効率と、侵害後に安全性を回復するために必要な追加処理を論じています。MLS は別の木構造ベースの方式を使います。これはアーキテクチャの違いであり、どちらかの設計が常に最良だとする順位付けではありません。
ポスト量子鍵確立がオーバーヘッドを増やす箇所
ML-KEM では、一般的な楕円曲線表現よりも大きい公開鍵とカプセル化の素材が加わります。しかし、プロトコルはメッセージごとに新たな KEM 交換を行う必要はありません。初期設定、定期的な鍵更新、通常の対称暗号化では、コストが異なり得ます。NIST FIPS 203 が定義しているのは ML-KEM のパラメーターセットであり、メッセンジャーの完全な通信形式ではありません。
そのため、KEM 暗号文のサイズに「100 人」を掛けるだけでは、100 人のチャットのメッセージ当たりの通信量を予測できません。答えはセッションの再利用、メッセージのフレーミング、受信デバイス、再送、添付ファイルを一度だけアップロードするか複製するかにも左右されます。
公平な比較では、グループ数とデバイス数、メッセージと添付ファイルのサイズ、メンバーの入れ替わり、クライアントのビルド、ネットワーク条件を明示します。こうした詳細がなければ、正確そうなキロバイト数やバッテリーの数値は誤解を招きかねません。
Livara による LGS1 の説明
Livara のセキュリティページは、LGS1 を非公開グループ向けの送信者チェーン方式と説明しています。各送信者の鍵素材は、一対一の LVR1 セッション内で配布されます。グループメッセージはそこから得られるチェーンを使い、文書ではメンバーの参加・退出時に新しい送信者鍵を使うと説明しています。
これは提供者が文書化したアーキテクチャであり、独立に検証された性能結果ではありません。鍵の配布と通常のメッセージをどのように分離する意図なのかを説明する根拠にはなります。しかし、グループのアップロードが毎回ちょうど 1.1 KB であること、システム全体の配信コストが O(1) であること、バッテリー消費が無視できるほど少ないと測定されたことを裏付けるものではありません。
鍵更新も安全性のためのコストの一部
将来の通信を復号できる鍵をメンバーがまだ持っているなら、画面からそのメンバーを削除するだけでは不十分です。安全な移行では、削除されたデバイスを新しい鍵の配布から除外し、残りのクライアントが正しい状態に移るようにする必要があります。すでに受信されたメッセージやコピーされたファイルを、暗号技術で取り戻すことはできません。
送信者鍵の前方秘匿性と侵害後の回復は、鍵チェーンの進め方、どの秘密情報を削除するか、新しい素材をいつ導入するかにも依存します。初期設定でポスト量子 KEM を使うというだけで、これらの性質を推測すべきではありません。
実用的なグループチャット評価のための質問
- 通常のテキストは送信者ごとに一度アップロードされますか、それとも受信デバイスごとに別々ですか？
- どのイベントで鍵を更新し、メンバーがオフラインの間は何が起きますか？
- 追加されたデバイスと削除されたメンバーはどのように表現されますか？
- 添付ファイルとその復号鍵は、同じメンバーシップ規則で保護されますか？
- どのメタデータが中継サーバーから見えるままですか？
- 想定するスマートフォンとネットワークで性能結果を再現できますか？
Livara の脅威モデルは、非公開グループと公開チャンネルを区別し、見えるルーティング情報を説明しています。公開配信と非公開グループの鍵配布を、一つの「暗号化チャンネル」という主張にまとめるべきではありません。
送信者鍵は重複する処理を省けます。工学的に有益な問いは、その処理がどこへ移り、どんなイベントで再び必要になり、グループがどれほど安全にメンバーを変更できるかです。
