素数がDiffie-Hellman鍵交換で再利用されるのはなぜですか？
Logjam攻撃 について読むと、Diffie-Hellman交換はしばしば 同じ特定の1024ビットキー に依存することを学びました。 DHが発明された当時は、512ビットのキーでさえ、何十年もの間安全であると考えられていたと理解しています。しかし、デザイナーや長年に渡ってDHの実装に取り組んできた多くのプログラマーが、同じ素数を再利用することで最終的な（破局的な）脆弱性が生じる可能性があるということは起こりませんでしたか？
計算が困難なものがないのですか？独自のpとgを1回生成すると、サービスは十分であるはずであり、標準化された素数の欠陥からの耐性を保証する必要があります。
*：同様に、現在の世界的な実装の3分の2がよくあります。
独自のDHキーexhcangeパラメータを生成し、標準のDHグループパラメータを使用することの難しさについて、次の質問を見ることができます。 独自のDiffie-Hellmanプライムを生成するか、RFC 3526で定義されているものを使用する方が安全ですか。 ？ および Diffie-Hellmanの素数はどこで取得できますか？それらを2回使用できますか？
単純なDiffie-Hellmanの場合、必要なのはp、qおよびg、そのような：
- pは十分に大きな素数です（現在、2048ビットで十分です）。
- qは小さいですが、それでも十分に大きく（たとえば256ビット）、割る素数p-1;
- gは、次の順序を持つサブグループモジュロpのジェネレーターです。 qの倍数。
ほとんどの状況では、実際の鍵交換が行われる前にDH鍵交換グループを作成することは容易ではなく、また適用できません。 logjamは、DHグループで使用される小さな素数（512ビット）を利用することに注意してください。グループが他のグループでも使用されている場合でも、2048ビットのpでDHグループを使用すれば安全だと思います。
3分の2の数字は、IPsecを使用するVPNサーバーに固有のものです。これは、システム管理者とセキュリティ担当者が、サーバーのデフォルト設定を構成中に絶対に必要とする以上の時間をかけて変更していないためだと思います。
または、VPNサーバーの特定のサブセットに関連するため、IPsecの特定の実装に問題がある可能性があります。たとえば、3分の2がCiscoのVPNまたはASAデバイスへの実装方法である場合（それらはハードウェアで実装されたVPNの世界的リーダー）、または一部のバージョンのLinuxがそれをサーバービルドに実装した方法、またはWindows Serverなど...いずれにしても、実際の問題よりも実装の問題のように思われるDHまたはIPsec自体。両方とも何年もの間セキュリティと暗号の専門家によって広範囲にわたって検討されてきたためです。 DHは単なるアルゴリズムであり、素数のXビットが提供されている限り、アルゴリズムはその役割を果たします。 IPsecは、セキュリティの実装に使用されるフレームワークです。実装は、フレームワークを介して、実際に素数を選択してアルゴリズムに提供するものです。