Qt: Rustで実装されたE2EEポストクォンタムメッセンジャーコア（124MB RAMで1万接続）

QT E2EEメッセンジャーの暗号化およびトランスポートコアの技術的プロトタイプ — X3DH、PQXDH（ポストクォンタム）、Double Ratchet、Sealed Sender、Noise Protocol、すべてRustで実装され、真剣にコンパイル・テストされています。これは完成品ではなく、実際の会話に使える状態ではありません — 探索に時間を費やす前に、以下の「正直に言って、これはもう機能しますか？」のセクションを参照してください。英語で読む → コンテキストこのプロジェクトは、プライバシーとシステムのセキュリティへの純粋な関心から生まれました — 特に、単なるポリシーではなく、設計によってバックドアに耐性のある通信インフラストラクチャをどのように構築できるかという問題（欧州連合で議論されている「Chat Control」のような法律などによって動機づけられています）。理論にとどまるのではなく、各部分を真剣に実装・テストすることを目標としました — 疑似コードではなく、図でもなく — コンパイルされ、実行され、それがやると言っていることを実行していることを確認する自動テストを備えたコードです。なぜこれが存在するのか（技術的な演習以外の目的）ほとんどの人気メッセンジャーは、登録のために電話番号を要求します。メッセージの内容がプライベートであっても、その登録は誰が誰と、いつ、どのくらいの頻度で話しているかという足跡を作成します。欧州連合では、いわゆる「Chatコントロール」のような法律も議論されており、アプリケーションは、たとえ「暗号化されている」と主張するアプリであっても、人々のメッセージの内容をスキャンすることを義務付けられる可能性があります。QTは、単なるプライバシーポリシーではなく、エンジニアリングでこれに対応しようとしています：暗号鍵に基づいたID（電話番号なし、メールアドレスなし）、サーバーでさえ解読できないエンドツーエンド暗号化、そして隠されたトリックがないことを誰でも確認できるオープンソースです。技術用語を一切使わない説明を好む場合は、apresentacao-projeto.mdから始めてください。正直に言って、これはもう機能しますか？はいでもあり、いいえでもあります — そして、プロジェクトを探索する時間を費やす前に、これについて明確にしておく価値があります。すでに機能しており、真剣にテストされています（単に「機能するはず」というコードではありません）：エンドツーエンド暗号化、ネットワーク層、メッセージを読み取ることなく配信するサーバー、実際の携帯電話で実行されたAndroidアプリ。これらすべてに自動テストが合格しており、いくつかの部分は私ができる限り厳密な方法で手動でテストされました（例：途中でサーバーを停止し、データが生き残ることを確認する）。まだ日常的に使用することはできません：完全なユーザーインターフェースが不足しています（今日のAndroidアプリには「デモを実行」ボタンしかありません）、サーバーをインターネットからアクセス可能な場所に配置する必要があります、そして実際の会話でこれに信頼する前に外部セキュリティ監査が必要です。言い換えれば、基盤は堅牢でテスト済みです。建物にはまだ屋根がありません。すでに構築されているものピース何をするか信頼core/セッション確立（X3DH + ポストクォンタムバリアント）と連続暗号化（Double Ratchet） — Signalが使用しているのと同じ設計✅テスト済み（14以上の自動テスト、意図的に失敗すべきケースを含む）transport/ネットワーク接続保護（Noise Protocol）WebSocket上✅シミュレーションではなく、実際のWebSocket接続でテスト済みserver/「郵便配達員」：内容を見たり、誰が送信したかを知ったりすることなくメッセージを配信✅強制停止（kill -9）からの生存を含むテスト済みstorage/IDと会話をディスクに保存、暗号化✅間違ったパスワードでは何も開かないことを確認するなど、テスト済みcli/ターミナルバージョン、電話なしで試すため✅完全に分離されたプロセスが互いに通信することでテスト済みffi/Kotlin（Android）、Swift（iOS）、Pythonにすべてを接続するブリッジ✅Pythonからテスト済みAndroidアプリこのブリッジを使用して、実際の携帯電話で機能することを証明✅実際のAndroidエミュレーターで実行済み率直に言って、何が欠けているかアプリの本格的なチャット画面（今はデモボタンだけ）インターネットからアクセス可能なサーバー、ローカルネットワークだけではないTLS（wss://）で保護された接続 — 現在は単純なws://を使用しており、テストにのみ適しています複数の独立したサーバーが協力する（フェデレーション）、これにより、単一のサーバーを停止するだけでネットワーク全体を停止させることができなくなりますデータベースパスワードを携帯電話のセキュリティシステム（Keystore/Secure Enclave）から取得、コマンドライン引数からではない私以外の人による独立したセキュリティ監査自分で試してみるこれを機能させる最も速い方法は、このコマンドです。架空の2人の間の完全な暗号化された会話を段階的に示すものです：cargo run -p qt_cli --bin messenger_demoコンパイル要件sudo apt install redis-server libsqlcipher-dev redis-server --daemonize yesRust via rustup — コアのポストクォンタムバリアントを除き、最近のバージョンならどれでも使用できます。ポストクォンタムバリアントにはRust 1.81以降が必要です。テストの実行cargo test --workspace #すべて、ポストクォンタムを除くcargo test -p qt_core --features pq #ポストクォンタムを含む永続クライアントとしての使用（2人、別々のプロセス）cargo run --bin relay_server &cargo run -p qt_cli --bin messenger -- identity --db bob.sqlite --passphrase "..."cargo run -p qt_cli --bin messenger -- register --db bob.sqlite --passphrase "..." --server ws://127.0.0.1:9443cargo run -p qt_cli --bin messenger -- identity --db alice.sqlite --passphrase "..."cargo run -p qt_cli --bin messenger -- send --db alice.sqlite --passphrase "..." --to <BOBのID> --message "Ola!" --server ws://127.0.0.1:9443cargo run -p qt_cli --bin messenger -- receive --db bob.sqlite --passphrase "..." --server ws://127.0.0.1:9443各人のIDは公開鍵から生まれます — 意図的に「ユーザー名」を選択する人はいません。Android/iOS/Python用のバインディングを生成する./ffi/generate_bindings.shプロジェクトの構成core/コア：依存関係なしのエンドツーエンド暗号化transport/ネットワーク接続を保護server/読み取ることなくメッセージを配信storage/すべてをディスクに保存、暗号化cli/ターミナルクライアント、電話なしでテストするためdemo/コア+トランスポートを単一のテストに結合し、すべてのアクションを見るためffi/Kotlin、Swift、Pythonへのブリッジdocs/完全な技術仕様と意思決定の履歴各ピースには、コードの隣に保存された独自のテストがあります（tests/）。Androidアプリは存在し、実際のデバイスで実行されました（上記のステータステーブルを参照）が、今のところ、独自のレポジトリや公開なしで、作成されたマシン上にのみ存在します — 技術的な概念実証として扱い、すでにインストールできるものとしては扱わないでください。公開される際には、このレポジトリを依存関係として使用する独自のレポジトリを獲得するはずです（CONTRIBUTING.mdで説明されている分離の原則と同じです）。技術的な詳細を理解したいですか？docs/protocol-spec.mdは、各ピースが内部でどのように機能するか、使用されているアルゴリズム、決定、および各ピースでまだ何が欠けているかをセクションごとに正確に説明しています。docs/threat-model.mdは、これがいかに誰に対して、何に対して保護するか — そして、それと同じくらい重要なこととして、いかに誰に対して、何に対して保護しないかを説明しています。ここに記載されているセキュリティ上の主張を信頼する前に推奨される読書です。ROADMAP.mdは、優先順位順に何が欠けているかを示しています。CHANGELOG.mdは、変更履歴を示しています。ライセンスQTはデュアルライセンスで提供されます：オープンソース：GNU Affero General Public License、バージョン3以降（AGPL-3.0-or-later）。商用：AGPL以外の条件を必要とする組織は、書面による合意により商用ライセンスを取得できます。商用ライセンスにより、使用、統合、配布、デプロイメント、サポート、メンテナンス、およびその他の商用権利に関する特定の条件を契約で定義できます。QTによって使用されるサードパーティコンポーネントおよび依存関係は、それぞれのライセンスの対象となります。AGPLライセンスについてはLICENSEを参照し、商用ライセンスモデルについてはLICENSE-COMMERCIAL.mdを参照してください。協力したい、または問題を報告したいですか？CONTRIBUTING.mdに方法が説明されています。