博士

やっほー、ロボ子！今日のITニュースはMessaging Layer Security (MLS) のお話じゃ。

ロボ子

MLSですか、博士。汎用性の高いグループ鍵合意およびメッセージングプロトコルですね。非同期およびリアルタイムアプリケーションを強化するために使われるとのことですが。

博士

そうそう！でも、MLSにはちょっとした課題があるのじゃ。特に、サーバーがいない環境だと、クライアント間で競合が起きて、Forward Secrecyに影響が出ることがあるんじゃ。

ロボ子

Forward Secrecy...過去の鍵が漏洩しても、それ以降の通信は安全であるという重要な性質ですね。

博士

その通り！そこで登場するのがDMLS！これは、Alwenらの研究に基づいて、その問題を解決するための仕様と実装なのじゃ。

ロボ子

DMLSは、MLSの課題であるグループ状態のフォークを許可するんですね。コミットの順序付けがない場合に、クライアントが古いグループ状態を保持できるようにする、と。

博士

そうじゃ！でも、ただフォークを許容するだけだと、Forward Secrecyが弱まってしまう。そこで、AMTという人たちが「Fork-Resilient Continuous Group Key Agreement」という論文で解決策を提案したのじゃ。

ロボ子

AMTの手法では、クライアントがコミットを処理する際に保持された共有鍵素材を「puncturing」できるようにMLSを変更するんですね。鍵素材を取得した攻撃者が新しいエポックの鍵素材を再計算するのを防ぐ、と。

博士

そう！DMLS = MLS + Fork Resilienceってわけじゃな。Puncturable Pseudorandom Function (PPRF) という技術を使って、鍵素材を部分的に削除するんじゃ。

ロボ子

PPRFですか。通常のPRFのようにランダムに見える出力を取得できるだけでなく、各呼び出しが基になる鍵素材をpuncturingするんですね。

博士

その通り！そして、OpenMLSという実装があって、DMLSを使うには、そのストレージプロバイダーを調整して、同じグループの複数のエポックを保存できるようにする必要があるんじゃ。

ロボ子

なるほど。DMLSストレージプロバイダーは、特定のエポックでのグループの状態をコピーし、その状態でのみ動作する通常のストレージプロバイダーを生成できるんですね。

博士

そういうこと！ただ、DMLSにはオーバーヘッドもあるんじゃ。ストレージの複雑さが増すのが主な欠点じゃな。

ロボ子

古いグループ状態の保持期間、グループサイズ、暗号スイート、フォーク頻度などがオーバーヘッドに影響するんですね。

博士

そうじゃ。でも、DMLSはフォークが避けられないシステムでForward Secrecyを改善するのに役立つから、セキュリティを向上させるための重要な要素になるんじゃ。

ロボ子

DMLSの実験に興味がある場合は、OpenMLSに基づくproof-of-concept実装を確認したり、Fork Resilienceの理論に興味がある場合は、AMTの論文を参照したりできるんですね。

博士

そういうことじゃ！もしDMLSを改善する方法について提案があれば、IETFのMLSワーキンググループに連絡してみると良いぞ。

ロボ子

よくわかりました、博士！DMLSは、分散システムにおけるForward Secrecyを強化するための重要な技術なんですね。

博士

そういうこと！最後に一つ、DMLSのDって何の略だと思う？

ロボ子

えっと...分散(Distributed)のDでしょうか？

博士

ブッブー！残念！ 正解は… **出汁(Dashi)のD！** …って、うそうそ！やっぱり分散(Distributed)のDじゃ！