Axolotl Ratchetプロトコルは電子メール通信の暗号化に適していますか？
Axolotlラチェットは、Signalメッセンジャー（以前はTextSecureとして知られていました）によって使用されます[〜＃〜] otr [〜＃〜]の拡張バージョンは、モバイルアプリケーションに適した方法で、メッセージを暗号化両方の当事者が同時にオンラインである必要はありませんここで説明 。鍵の交換が非同期で行われています。
Signalは、順不同の復号化や、メタデータがクリアテキストを介して漏洩するのを防ぐなど、他のいくつかの問題も解決します。
これは PGP、Forward secrecy（PFS）および他のいくつかの問題が欠如している の代わりとして完璧に聞こえます。
PGPの代わりに axolotl 暗号化を使用するメールクライアントプラグイン（ThunderbirdのEnigmailなど）を作成する場合、どのような問題を考慮する必要がありますか？
きちんとしたアイデア、良い質問ですが、axolotlを既存の電子メールクライアントやサーバーに適したドロップインソリューションにしないいくつかの問題があります。
1）TextSecureの非同期部分には、電子メールサーバーが提供しないサーバーからの助けが必要です。具体的には、TextSecure/Signalサーバーは、オフラインユーザーに一時的な公開キーを配布します。メールサーバーはそうではありません。
2）Axolotlクライアントは必ずステートフルであり、すべての会話の主要なラチェットを追跡します。これは（再び）電子メールクライアントが提供するように構築されている機能ではなく、電子メールクライアント間でその状態を同期する必要があるため、複数の電子メールクライアントを使用することが困難になります。例えば。デスクトップメールクライアントは、スマートフォンメールクライアントによって生成されたすべてのキーを取得する必要があります。
ただし、電子メールの代替としては最適です。その問題に取り組みたい場合は、TextSecureまたはPond用に開発中のWebクライアントを確認してください。 Textsecure/Signalにはデスクトップクライアントが必要で、Pondにはモバイルクライアントが必要です。
Axolotlのラチェットは優れており、いくつかの優れたセキュリティプロパティを提供しますが、axolotlが提供するセキュリティ保証は、多くのユースケースでの状態維持の煩わしさには見合わないという議論があります。
エンドツーエンドで暗号化する必要がある非同期メッセージング、電子メールなどには Pond をお勧めします。池はアホロートルラチェットを前方秘密に使用しますが、池はトラフィック分析からの保護も提供します。
送信する暗号化されたメッセージの量やメタデータなどを偽装するのは、価値のないことです。どのメールシステムでも、メタデータをトラフィック分析に公開します。一時的なメッセージや、Pondを使用しない人々とのたまにあるやり取りにはGnuPGを使用することをお勧めしますが、Pondを使うように定期的なやり取りを説得してください。
興味深いプロジェクトとしては、池の接続を自動的に確立しようとするメールクライアントがあります。
電子メールにaxolotlを使用するという考えが適切かどうかはわかりませんが、試してみる価値はあります。私のチーム Tradle は、@ geargewalkerが提案したような電子メールの代替を作成することを選択しました。それでも、ここにいくつかの指針があります：
- @georgewalkerが言及した最初の問題は解決可能です。 PGPには常に公開鍵サーバーがありましたが、使いづらくて使いにくいものでした。 Trust In Motion（TiM）と呼ばれるメッセンジャーの一部-プレビューはWebサイトにあり、ブロックチェーンをキーサーバーとして使用します。メールプラグインのアイデアにチェーンの公開鍵のソリューションを使用するために必要なすべての支援を提供できます。 TiMはオープンソースであり、間もなくプライベートベータ版に入るので、コードの使用を開始できます。
- 他のメールクライアントがAxolotlをサポートしている必要があることは明らかですが、会話スレッドごとに、メールクライアントの状態を維持することで当面の問題は見られません。 Axolotlプロトコル自体には 代替のサードパーティJS実装 があります。
幸運を。