概要
Twitterの新しい暗号化メッセージ「XChat」は、改善された点もあるが本質的な安全性に問題が残る。 依然としてTwitterはユーザーの秘密鍵を取得できる可能性が高く、MITM攻撃やメタデータ漏洩のリスクが存在。 JuiceboxプロトコルやLibsodiumの採用など技術的な工夫はあるが、PINやキーストアの運用に課題。 サーバーやバックエンドの信頼性が担保されておらず、Signalのような先進的な安全性は実現できていない。 結論として、プライバシー重視ならSignalの利用が推奨される。
Twitterの新暗号化DM「XChat」の問題点
- Twitter は数年前に暗号化DMを導入したが、 エンドツーエンド暗号化（e2ee） としては不十分な実装。
- 当初は画像送信などの機能もなく、実用性に乏しいサービス。
- 最近、Elonが「 XChat」という新しい暗号化メッセージングを発表、 Rust製アーキテクチャ とBitcoin風暗号化を採用。
- しかし、 根本的な安全性の問題 は解決されていない現状。
技術的な構成とその限界
- 新実装は Libsodiumのboxes を用いたメッセージ暗号化を採用。
- これは 前方秘匿性（Forward Secrecy） を持たないため、秘密鍵が漏洩すれば全ての過去メッセージが解読可能。
- Signal は10年以上前から前方秘匿性を実現しており、現代的な基準には及ばない。
- Libsodium の実装はC言語であり、Rustではない。
- 従来方式では、各クライアントがキーペアを生成し、公開鍵のみをTwitterにアップロード。
- 新デバイスでは過去メッセージを復号できず、デバイス数に制限がありスケーラビリティにも課題。
JuiceboxプロトコルとPIN運用のリスク
- 新方式では Juiceboxプロトコル を使い、秘密鍵をサーバーに保存。
- 秘密鍵はPINで生成した鍵で暗号化され、PINを知らなければ復号不可。
- PINは4桁固定 で最大10,000通り。Argon2idによるKDFを用いても、並列計算で短時間に総当たり可能。
- Juiceboxは 複数バックエンドへのシャーディング をサポートするが、Twitterは自社管理の3つのバックエンドのみ使用。
- いずれもx.comドメイン配下であり、 Twitterが全て管理。
バックエンドの信頼性とMITMの懸念
- キーストアの信頼性は、 バックエンドとクライアント間の通信の真正性 に依存。
- HSMの検証や試行回数制限プロトコルが必要だが、Twitterはその証明やドキュメントを公開していない。
- クライアントは相手の公開鍵をTwitterサーバーから受け取るのみで、 公開鍵の真正性検証手段が存在しない。
- Twitterが任意の公開鍵を渡せば、 MITM攻撃 が容易に成立。
- サポートページでもこの点は「今後修正予定」とされているが、過去の暗号化DMでも未解決のまま。
メタデータ漏洩とプライバシー
- サーバーは 誰が・いつ・誰にメッセージを送ったか というメタデータを常に把握可能。
- たとえ暗号化が突破されなくても、 通信のパターン から多くの情報が漏洩。
Signalとの比較・推奨
- Signal は前方秘匿性・公開鍵の真正性検証・メタデータ保護など、 現代的な安全性 を実装。
- TwitterのXChatは、 安全性・プライバシーの観点でSignalに大きく劣る。
- プライバシー重視ユーザーには Signalの利用を推奨。
補足・注釈
- JuiceboxにはRust実装も存在するが、TwitterはC実装をJNI経由で利用。
- バックエンド運用者が悪意を持つ場合や、法的圧力下で秘密鍵の取得が現実的なリスク。
- GoogleやAppleは、Intel SGX等を用いたより安全なキーストア運用をドキュメント化。
結論: Twitterの「XChat」は技術的な進歩はあるものの、 本質的な安全性・信頼性は確保されていない。 Signal の利用が、現時点では最適な選択。