Diffie-Hellman大きな素数の弱点。この概念は有効ですか？もしそうなら、エンドユーザー/管理者はこれをどのように修正できますか？
だから私はこのブログ投稿を 「How is is NSA Breaking so much crypto ??） を見ました。このブログ投稿の基本的な考え方はこれです：固有の弱点がありますデフォルトで同じ大きな素数を使用するサービスに由来するDiffie-Hellman。つまり、その1つのデフォルトの大きな素数が変更されない場合、そのデフォルトの大きな素数がハッキングされて一般に知られていると、その値が変更されていないシステムは比較的単純になります。
聴衆のオタクにとって、これは何が問題なのかです。クライアントとサーバーがDiffie-Hellmanを話している場合、彼らは最初に特定の形式で大きな素数について合意する必要があります。誰もが同じ素数を使用できない理由はないようで、実際、多くのアプリケーションは標準化された、またはハードコーディングされた素数を使用する傾向があります。しかし、数学者と開業医の間の翻訳で失われた非常に重要な詳細がありました。敵は特定の素数を「クラック」するために単一の膨大な計算を実行し、その素数を使用する個々の接続を簡単に解除できます。
わかりました、私はここでコンセプトを完全に購入していません。しかし、この記事の前提が真であると仮定すると、さまざまなDiffie-Hellman配置で同様のデフォルトの素数を使用すると、固有の弱点が生じることになります。その場合、私の質問は次のとおりです。
Diffie-Hellman実装の主要な攻撃面である展開遅延（デフォルトの大きな素数を提供することによってマークされている）が、もしあれば、平均的なエンドユーザーとシステム管理者が実行できること—この問題を先制的に無効にするには？
暗号化のビルディングブロックを理解する私の能力の奥底に少し踏み込んでいる可能性がありますが、その記事に示されている弱点の概念は、たとえば、認証局が新しいルート証明書を発行することを必要とするものですか？それが起こらない限り、一般的に使用されているデフォルトのDiffie-Hellmanの大きな素数の脆弱性は依然として懸念事項であり、潜在的な脆弱性でしょうか？
または "thruthy" に類似していると見なすことができる Y2Kバグを取り巻くパニック に基づくそのブログ投稿の全体的な仮定は、ある程度のレベル-懸念に関連するパニックを正当化するのに十分な規模で実際に現れたことはありませんか？
2048ビットまたはそれよりも優れた3072ビットより小さい素数グループでは、DHを含む暗号スイートを使用しないでください。それがシステム管理者としてできることです...
EFFには実用的なアドバイスがあります： https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH