Diffie Hellmanエフェメラルキーは、対称暗号アルゴリズムキーとして使用するのに適した材料ですか？
私は（学術/学習目的で）安全なプロトコルを設計しており、鍵交換ステップを（再）設計する必要がある段階にあります。
以前の実装では、RSAを使用して暗号化し、ランダムに生成された2つのAESキーに署名し、トラフィックの暗号化に使用していました。
鍵交換にDiffieHellmanを使用すると、私のニーズによりよく適合する可能性があることに気づきましたが、十分に理解していないアルゴリズムを使用するのはあまり快適ではないため、質問があります。
EC-DHEを使用したいのですが、生成されたキーがランダムではないことを読みました（読み：構造があり、基礎となる数学的概念に由来すると思います）。対称暗号アルゴリズムでは、ランダムに生成された鍵を使用することが強く推奨されるといつも聞いていました。結果のDHE鍵をハッシュしても、「ランダム」にはなりません。その目的で使用しても大丈夫ですか？
EC-DHEでは、楕円曲線の選択は基本的にDHパラメーターを選択する簡単な方法であることを理解しました（間違っている場合は訂正してください）。楕円曲線を選択するときに注意すべきことはありますか？使用できるECをユーザーに決定させる必要がありますか？
DH（楕円曲線の有無にかかわらず）は、共有秘密になります。その秘密は、いくつかの代数的性質を持つ数値です。しかし、すべての秘密はそれに含まれています。じゃがいもをウォッカに変えるのと同じように、蒸留するだけです。
256ビットの楕円曲線を使用しているとします。 NISTの標準P-256曲線。ワイヤーを介して送信される要素はカーブポイントであり、それぞれが正式には256ビットフィールドの座標のペア（X、Y）です。 DHの結果は別の曲線点であり、標準によれば、その最終点の[〜＃〜] x [〜＃〜]座標は共有秘密。 256ビット値です。このような曲線では、ECDHは「128ビットセキュリティ」（これは良い）を提供することになっているので、共有秘密にはどういうわけか128ビット相当の秘密が含まれています。その秘密は実際の256ビットに「広がっている」。したがって、その256ビット値にも構造の余地があります。
結果の256ビットを「現状のまま」使用することは、その余分な構造の範囲と、それを外部でどのように利用できるかを判断するのは容易ではないため、通常は賢明ではないと考えられます。これらの256ビットを切り捨ててAES/HMACなどのキーに分割できるビットのシーケンスに変換するには、最も簡単な方法は、ハッシュ関数を使用してそれらをハッシュすることです。たとえば、SHA-256を適用すると、256ビットが再び取得され、安全に分割して必要に応じて使用できます。より一般的なケースでは、 鍵導出関数 を使用します。
曲線の選択に関して：実装で正確な曲線をハードコーディングすることにはパフォーマンス上の利点があるため、ほとんどの既存のライブラリは、ほんの一握りの特定の曲線のみをサポートします。 SSL/TLSでは、楕円曲線を使用する場合、クライアントはサポートする曲線の記号指定のリストを送信し、サーバーはこれらの曲線の1つを選択します。実際には、誰もがP-256を使用しています。もちろん、カスタムプロトコルでは、他の曲線を選択できます。 任意の曲線を動的に使用するように指示することもできますが、その場合は、曲線パラメーターを送信するための準備を行う必要があり、これは面倒です。ほとんどのECライブラリは任意の曲線をサポートしていないため、実装用です。
楕円曲線の作成は、DHパラメーターを選択するよりも計算コストが高くなります。楕円曲線の作成は簡単な作業ではありません。
次の質問と回答を確認することをお勧めします。 カスタム楕円曲線を一般的なTLS実装で使用できますか？ 。
そのスレッドで言及されているように、OpenSSLでより広く受け入れられている「名前付き曲線」のいくつかから離れすぎると、互換性と実装の問題が発生する可能性があります。ユーザーが任意の曲線を指定できるようにするのは実用的ではないようです。