対称鍵から非対称鍵へのハンドオフ

Question

私は暗号化の専門家ではありません。実際に暗号化を使用した経験はほんの少ししかありません。とにかく、アプリケーションの 1 つが暗号化の設定を要求する時代が来ました。このプログラムでは、多大な損害を引き起こす可能性のある超重要なものは管理されないことに注意してください。

とにかく、私が使用しているこのスキームが一般的であるかどうか、そして欠陥があるかどうかを確認しようとしていただけです（完全に愚かでひどく欠陥のある設計がある可能性があります。それが私が質問している理由です）。

OK、クライアント -> サーバー通信ができました。クライアントは、2048 ビット RSA キーの公開部分にハードコーディングできます。クライアントが安全な接続を開始したい場合、ユーザー名、パスワードの md5 ハッシュ、およびランダムな UUID のハッシュを送信します。これらはすべてサーバーの公開キーに対して暗号化されています。サーバーは情報を受信し、その秘密キーを使用して復号化します。データベースをチェックして、ログイン + パスが機能するかどうかを確認し、機能する場合は、DB の「セッション」テーブルに新しいエントリを作成します。これには、SessionID、UID (ユーザー ID)、および UUID ハッシュが含まれます。対応するセッションIDのUUIDをキーフレーズとして使用すると、サーバーは、Flowfish暗号化された単語「Success！」を含むメッセージを返送します。 +ランダムuuid（このメッセージはデジタル署名されているため、サーバーから来たかどうかを判断できます）。その時点から、クライアントがサーバーに情報を送信するときは、平文の sess_id が使用され、対応するセッション ID の Blowfish シークレット (DB に暗号化されて保存されている) を暗号化/復号化のキーとして使用して、Blowfish 暗号化メッセージが含まれます。

具体的には、このシステムは「機能するはず」なのか、それとも MITM などの脆弱性が存在することが明らかであることに誰かが気づいたのかどうかに興味があります。

Answer 1

私が頭の中で認識できる問題点は次のとおりです (ただし、詳細のほとんどは省略されていますが、そこに悪魔が住んでいることで有名です)。

• 実際の暗号化 RNG ではなく UUID ジェネレーターを使用している場合は、エントロピーが不十分である可能性があります。これを軽視しないでください。現実の世界では、暗号化システムを密かに弱体化する好都合な方法は、RNG を弱体化することです。

• 最初の RSA 暗号化は、小指数攻撃やその他の創造的な攻撃の影響を受けやすいように思えます。そこには快適に過ごすには構造物が多すぎる。

• リプレイ攻撃の機会は数多くあるようです。

• Blowfish ではどのブロック暗号モードを使用していますか?

私は TLS/SSL を使用することをお勧めします。これは、自分で構築するものよりもはるかに長い間、ずっと友好的な目で見られてきました。

Answer 2

ただ、SSLまたはDTLS、IKEv2の、HIP、EAPまたはいくつかの適切な標準プロトコルを使用しています。誰もが自分でこれを行うのに十分な専門知識を持っていない、独自の暗号化プロトコルを発明しようとしないでください。あなたのプロトコルはこれまでのところ、私が見ることができるように、それにほぼ十分なエントロピーを持っていないので、あなたの結果のキーはかなり弱くなります。

Answer 3

  クライアントがサーバーに情報を送信するときに

その時点から、それは平文sess_idとなります＆暗号化/復号化するための鍵として、対応するセッションIDを使用して、フグ暗号化されたメッセージが含まれます。

あなたが平文でセッションIDを送信し、暗号化キーとしてそれを使用している場合は、

、どのように安全なことでしょうか？

私はあなたが標準のSSL認証を使用し、ハンドシェイクについてのライブラリ実装者の心配をさせないことができない理由を見ない。