TLSサーバーで同じDHパラメーターを使用する意味は何ですか？
DHE暗号の場合、nginxはDiffie-Hellmanパラメータをハードコード化し、カスタムDHパラメータが設定されていない場合、ベース2と固定の1024ビットプライム（係数）を使用します。
これらのパラメーターはパブリックです（TLS ServerKeyExchangeメッセージでプレーンテキストで送信されます）。素数の値を変更すると、TLS接続のセキュリティが向上しますか？ビット数ではなく、異なる素数を持つことの効果に興味があります。
クライアントとの互換性の問題など、DHパラメータの変更による他の副作用はありますか？ （ Apacheは、Java 7以前 でより大きな素数を使用した結果の問題について話していますが、OpenJDK 1.7.0_40ではこれを再現できません。）
他の人/サーバーと同じDHパラメータを共有することによる既知の悪い副作用はありません。これは実際、elliptic-curveDHの一般的なケースです。なぜなら、独自の曲線を生成することは、古典的なDHの独自の素数を生成するよりもかなり難しいためです。また、楕円曲線の通常の実装は、特定の曲線または小さな曲線のセットに関連付けられています（これは、このように記述する方が簡単で効率的だからです）。
攻撃者が特定の素数を法で「壊す」- 離散対数 モジュロに多くの作業を投資し、中間計算を再利用してその特定を法として機能する多くのDHインスタンスをすばやく破壊する方法について、理論的な懸念がありました。プライム。その意味で、共通のDHパラメータを再利用することは、攻撃者にとって迷惑行為の追加の力を意味する可能性があります。ただし、この種のコスト共有はすべてのDL破壊アルゴリズムで機能するわけではありません。これは、攻撃者がが失敗した可能性があることも想定しています破壊DL素数を法として、つまり素数が短すぎるか、「特別な形式」である。これは、その素数を使用しないほうがはるかに差し迫った理由になるでしょう：shared、しかしそれはweakです。
したがって、既存の共有DHパラメータを使用することは、上記のパラメータが高速（より）の中断を可能にするために特別に「調理」されていないことを確認できる限り、問題ではありません。これは通常、生成アルゴリズムが完全に指定されており、忠実にフォローされていることを確認できることを意味します（例： these ones を参照）。
カスタムのDHパラメータを使用すると、すべてのクライアントで機能します。実装を特定の係数に結び付けることには利点がありません（楕円曲線とは異なります）。モジュラスが特定の実装のサイズ要件に適合している限り、問題はないはずです（一部の古い実装では、1024ビットを超えるサイズで問題が発生します。他の実装では、サイズが32ビットまたは64ビットの倍数でないモジュラスは好ましくありません。 ）。
1024ビットの素数は、計算範囲内にあり、州レベルのアクターからの事前計算攻撃に対して脆弱です。
https://weakdh.org/ は、この質問のコメントで言及されている問題と、logjamダウングレード攻撃について説明しています。