木の図と送信者鍵の図を比べるだけでなく、定義された操作のコストと、定義された脅威に対する証拠を比較しましょう。
Messaging Layer Security（MLS）と Livara の LGS1 は、互いに置き換えられる二つのグループチャット安全証明書ではありません。MLS は IETF のプロトコル標準であり、LGS1 は Livara が文書化した製品固有の設計です。 公平な比較には、アーキテクチャ、実装の証拠、ユーザーが実際に体験する動作を区別する必要があります。
重要な違いは、木構造に基づく共有グループ状態と、二者間セッションで配布される送信者鍵です。どちらの名前だけでも、特定のアプリが削除されたメンバー、古い状態の端末、侵害された鍵を正しく扱えるかは分かりません。
アーキテクチャの違い
RFC 9420 は、非同期のグループ鍵確立のために MLS を規定しています。ラチェットツリーとグループエポックを使用し、明記された条件下で前方秘匿性と侵害後の安全性を提供します。木構造はグループ規模の拡大に伴う一部の鍵更新コストを抑えます。
Livara のセキュリティ文書は、LGS1 をメンバーごとの署名付き送信者チェーンと説明しています。これは LVR1 の二者間セッションを通して配布され、メンバー変更時に更新されます。これは製品の主張であって、LGS1 が MLS に準拠することや、同じ分析を受けたことの証拠ではありません。
| 問い | MLS | Livara LGS1 の文書 |
|---|---|---|
| 共有構造 | ラチェットツリーとエポック | 送信者ごとのチェーン |
| 鍵更新 | グループ状態の変更を新しいエポックにコミット | 新しい送信者鍵をメンバーに配布 |
| 仕様の位置付け | IETF 標準 RFC9420 | 公開された製品固有の説明 |
| なお評価が必要なもの | アプリへの統合と実装 | 完全な仕様、実装、独立した証拠 |
この表は設計上の分類です。ベンチマークでも安全性の順位付けでもありません。
「対数的」が意味すること、しないこと
暗号上の更新で暗号化された木の経路要素を対数個使っていても、システムのすべての作業量が対数的になるわけではありません。メッセージの配布やクライアントの状態保持は依然として必要で、動作はグループ構造と操作に左右されます。以前の「MLS は O(log N) 個のメッセージが必要だが、LGS1 はすべて速い」という比較は、異なるコストを混同し、測定を示していませんでした。
MLS アーキテクチャの RFC 9750 は、配送サービスを暗号学的な鍵確立と分けて扱い、メッセージ配布とグループ変更の順序を論じています。この分離は重要です。クライアントの計算、コミットのバイト数、サーバー全体の配布量、再接続時の通信量は別の指標です。
意味のある性能報告には、次を記すべきです。
- グループ規模と一人当たりの端末数。
- 通常のメッセージ、メンバー削除、鍵更新、再接続のどの操作か。
- 開始クライアントが送信するバイト数と配送全体の通信量の区別。
- 経過時間、端末機種、実装バージョン、ネットワーク条件。
- 取り逃した更新と繰り返されるメンバー変更のコスト。
これらがなければ、「ミリ秒」「状態管理の負荷が低い」、特定のグループ規模での優位性などは立証されていません。
メンバー削除はライフサイクルの試験
管理者によるアカウント削除は、安全性の一部分でしかありません。クライアントは新しいメンバー状態に合意し、適切な新しい鍵を使用し、除外された端末へそれを渡さない必要があります。古い平文や鍵をすでに持っている人は、過去の内容へのアクセスを維持する可能性があります。削除してもコピーは消せません。
どちらの方式でも、有用な試験は次を問います。削除完了後、削除された端末は機密性のない新しいテストメッセージを復号できるか。オフラインだったメンバーは安全に追い付けるか。アカウントに属するすべての端末を処理できるか。画面に失敗やメンバー変更が表示されるか。
これらは提案する評価項目であり、ここで実施した試験結果ではありません。製品比較では、管理者のクリック成功を暗号学的な排除と同一視せず、観察結果と試験したバージョンを公開すべきです。
前方秘匿性と復旧には条件がある
後の侵害から過去のメッセージを守るには、古い秘密素材の退役が必要です。将来のメッセージの保護を回復するには、攻撃者が関連するアクセスを失った後に新しい秘密を取り込む必要があります。MLS ではグループ更新の処理が復旧の一部です。更新を送信しただけでは、全員が適用したことになりません。RFC 9420 のセキュリティ上の考慮事項を参照してください。
送信者鍵設計では、各送信者の侵害された状態をどう置き換え、再配布するかを尋ねましょう。一方向チェーンだけで、現在の状態を知る攻撃者から自動的に回復すると説明すべきではありません。再配布に使う二者間の保護は重要ですが、グループ全体の分析の代わりにはなりません。
耐量子性の主張には具体的な暗号スイートと範囲が必要
基本の RFC9420 が定義する暗号スイートは、従来型の公開鍵方式を使います。MLS は拡張可能なので、特定の実装については実際のスイートと拡張を明示し、すべての MLS 配備が永久に従来型だと決め付けないことが重要です。
LGS1 がハイブリッド LVR1 配布を使うという文書上の説明は、すべてのグループ操作について独立に分析された耐量子保証とは異なります。FIPS 203 は ML-KEM を標準化しますが、それを組み込むグループプロトコル全体を認証しません。KEM の名前だけでなく、認証、メンバー変更、鍵の侵害、実装を合わせて評価してください。
製品を選ぶ前に求めるべきもの
現行のプロトコル仕様、テストベクトル、未解決の指摘を含むリリース固有の独立レビューを求めましょう。その上で、対応端末、更新動作、復旧、管理者の役割、サーバーが保持するデータなど、通常の製品要件を比較します。
MLS アーキテクチャは、アプリケーションサービスとその信頼の前提を明示的に考慮します。同様に、Livara の脅威モデルも製品の主張と併せて読むべきです。暗号化は、権限のある参加者を誠実にしたり、スクリーンショットを防いだり、あらゆるメタデータをなくしたりしません。
証拠がなければ、設計を自動的に危険または優秀と決めず、「未立証」と記録します。判断には、グループのリスクと利用可能な証拠の質を反映させるべきです。
よくある質問
LGS1 は MLS の実装ですか？
公開された説明では異なるアーキテクチャが示されています。この記事は LGS1 を MLS 実装と認定せず、相互運用性も主張しません。
MLS は全員の同時オンラインを必要としますか？
いいえ。非同期利用は設計の一部です。ただしアプリには、遅延更新、古い状態、長期間オフラインのメンバーに関する方針が必要です。
耐量子鍵配布でグループの安全性は解決しますか？
いいえ。鍵確立の一部に対処するものです。本人性、メンバー構成、鍵のライフサイクル、端末の安全性、実装には、なお証拠が必要です。
どちらの設計が速いですか？
この記事には勝者を確定するベンチマークはありません。グループにとって重要な操作と配備環境を測定してください。
