注:この質問は Threema メッセンジャーに固有であり、暗号化の実装に関連しています( NaCl[〜#を使用して〜] ecdh [〜#〜] 彼らのドキュメントによる実装)
私は特に彼らの「発信メッセージに関する注意」を彼らの ウェブサイトの検証文書 で参照しています:
送信者の秘密鍵と受信者の公開鍵を入力することによって、つまり受信者の秘密鍵を知らなくても、送信メッセージを解読できるのは奇妙に思えるかもしれません。 ...
さて、このシナリオを考えてみましょう:
ボブのキーとトラフィックを使用して、イブはボブがアリスに送信したすべてのコンテンツを復号化できますか?
つまり、Threemaでは、受信したコンテンツのプライバシーはSENDERの秘密鍵の安全性に依存していますか?
質問1:
ボブのキーとトラフィックがあれば、イブはボブがアリスに送信したすべてのコンテンツを解読できますか?
はい。
それは「前方秘密」についてであり、Threemaがセッションキーを管理する方法に依存します。 (ウィキペディアから: "Forward secrecyは、過去のセッションを、秘密鍵またはパスワードの将来の侵害から保護します。" )
考慮すべき点が2つあります。
モバイルメッセンジャーには本質的に非同期の性質があるため、エンドツーエンドレイヤーで信頼できるForward Secrecyを提供することは困難です。新しいチャットセッションのキーネゴシエーションでは、最初のメッセージを送信する前に相手がオンラインである必要があります...これらと以下の考慮事項により、Threemaはトランスポート層に転送秘密を実装しましたのみ
キー導出のためのソルト。
crypto_box_open()
は、次のデフォルトのソルトでキーを生成する validation Primerに従ってそこで使用されます。_static const unsigned char sigma[16] = "expand 32-byte k";
static const unsigned char n[16] = {0};
_
最後に、暗号化キーは次の疑似式によって計算されます。
KEY = HSALSA20(DH(privkey, pubkey), n, sigma);
そしてそれは、エンドツーエンドの暗号化の暗号化キーがアリスとボブの間で変化しないことを意味しますThreemaで。
質問2:
受信したコンテンツのプライバシーはSENDERの秘密鍵の安全性に依存していますか?
はい。
それはもっと広い問題だと思いますが、秘密鍵が危険にさらされると、プライバシーが危険にさらされます。受信者の秘密鍵が危険にさらされている場合、受信したコンテンツはサードパーティによっても復号化できます(鍵=受信者の秘密鍵*送信者の公開鍵)。
Diffie-Hellman鍵交換の場合、同じ鍵ペアが使用される場合、作成される共有秘密は同じになります。これは、イブが送信者または受信者の秘密鍵を取得した場合、共有シークレットを計算し、アリスとボブの間の過去および将来のすべてのメッセージを復号化できることを意味します。この問題を回避する一般的な方法は、エフェメラルキーを使用して、共有シークレットがその特定のセッションでのみ有効になるようにすることです。
ただし、Theemaの場合、エンドツーエンドの暗号化では一時的なキーを使用せず、トランスポート層での転送の機密性のみを保証します 暗号化ホワイトペーパー に記載されています。彼らの述べた正当化は:
送信者とサーバーの間、またはサーバーと受信者の間のインターネットを介した任意のパスでの盗聴のリスクは、サーバー自体での盗聴のリスクよりも桁違いに大きい
つまり、質問に直接答えるために、Theemaのメッセージはトランスポート層の転送セキュリティのみなので、攻撃者が暗号化されたメッセージと送信者または受信者の秘密鍵を持っている場合、それらを復号化できます。
「ネットワークトラフィックをキャプチャした攻撃者は、事後にクライアントまたはサーバーの長期秘密鍵を見つけても、それを復号化することはできません。」