その他

Certificate Transparency

まだ不勉強なため後ほど追記予定です

クライアントの見える化

E2EE の仕組みはクライアントとサーバの実装が悪意がないことが前提に組まれています。

どれだけ E2EE を実装したとしても、クライアントがクローズドソースな場合、 クライアントからこっそりとマテリアルキーをサーバに送っていたらそれはもうどうしようもありません。

そのため、すべての通信が目に見えるブラウザでの実装がとても重要になると考えています。

実際 Signal は提供している Android クライアントが、オープンソースで公開されているものと同一かどうかを確認する方法などを紹介しています。

Signal >> Blog >> Reproducible Signal builds for Android

クライアントのソースコードが公開されていない場合は、 E2EE が行われているかどうかを確認するのが困難です。

E2EE と匿名性

E2EE 自体には実は匿名性というものは含まれていないと考えるのが一般的です。 ただ E2EE を利用したメッセージングサービスの多くが匿名性を強みにしていることから E2EE は匿名性ありきと考えがちです。

E2EE はむしろ「参加者が信頼できるかどうか」の方が重要だったりします。 このあたりは Zoom のホワイトペーパが詳しく書いていますので興味がある人は読んでみてください。

End-to-End Encryption for Zoom Meetings

今後の WebRTC SFU を利用した場合の E2EE 実装

X3DH と Double Ratchet と SFrame を利用した仕組みがまず広まっていくと思います。 現時点で実現できているのは Google Duo だけです。

その後 MLS を利用した仕組みに置き換わっていくと考えています。 ただ MLS 自体はそんなに一気に広まっていくとは考えていません。ゆっくり時間をかけて検証する必要があるためです。

ただ Google Duo はブラウザでの E2EE を WebAssembly を利用して実現してきており、本気を感じさせます。