Logjam を軽減する方法に関する多くのチュートリアルでは、 regenerate Diffie-Hellman係数を推奨しています。これは、特に高ビットグループの場合、リソースを大量に消費する操作です。
これは、ダウンロード用のモジュラスファイルを提供する小さなサービスを構築するのが理にかなっているのか、毎週再生されるのか、と私は考えました。 OpenSSHは、生成された素数の安全性を -T
オプションのssh-keygen
util でチェックする方法を提供するため、ユーザーは素数が安全であることを確認できるはずです。これは、多くの候補を生成し、それらの中で安全な素数をチェックするよりも大幅に短い時間で済みます。
今私の質問は:この手順は、外部のモジュラスファイルが何らかの形で「バックドア」されていないことを確認するのに実際に十分ですか?攻撃者はそこに特別に細工された値を入れて、ユーザーが気付かないうちに鍵交換を破ることができるでしょうか?
リンクされた記事をありがとう@ StackzOfZtuff。それらを使用して、これは私が今までにつなぎ合わせたものです:
生成されたパラメータは、頻繁に再生成される限り、おそらく信頼できます。セキュリティを強化するには、再利用されたパラメータをチェックする必要があります。これは、何か怪しいことが起こっていることを示している可能性があります。自分のマシンでパラメータを生成する方が安全です。
名前が示すように、安全な素数は、結果のグループの特定のサイズを保証するため、DHグループを生成するときにうまく機能します。したがって、意図的に悪い素数がグループサイズの縮小につながることは、質問で説明されているスキームでは問題になりません。
私が見る可能性のある攻撃の1つは、生成エンティティが特定のグループを選択し、可能な限り事前計算して、自然界ふるいを使用して離散対数問題を解決できることです。これにより、攻撃者がそのグループを使用してDHを破壊するのがはるかに簡単になります。当然、事前計算ステップは計算コストがかかるため、攻撃者は壊れたグループを可能な限り再利用したいと思うでしょう。これは、以前のグループを追跡することで検出できます。
繰り返し発生するグループのチェックを行う代わりに、自分のパラメータを計算する方がおそらく簡単です。 nothing-up-my-sleeves保証なしで、他の人が生成したDHパラメーターを使用するには、基礎となる素数が安全かどうかに関係なく、それらの新しいグループを提供するエンティティへの信頼が必要です。
グループのDHパラメータが操作される可能性があるというリスクは別として、攻撃者のコストを評価する場合、これも意味がありません。
多くの計算能力を持つ誰かが直接あなたのサービスをターゲットにしていると仮定する場合、うまくいけば、どこかにダウンロードしたばかりのパラメータを使用しないでしょう。
NSAのように、あまり具体的でないターゲティングを恐れている場合は、おそらくあなたをターゲティングしませんが、トラフィックをチェックするのにそれほど費用がかからない場合、彼らはあなたがそうでないことを確認するためだけに見えるかもしれませんa コミュテロリスト、それならこれはリスクを高めるでしょう。自分だけが使用するパラメーターを生成する場合、それらはデータをスヌープすることしかできません。 10000人が毎週自動的に変更するために使用するパラメーターを使用する場合、このパラメーターを壊すことは攻撃者にとって10000倍の価値があります。
したがって、x人が毎週変更されたパラメーターを使用すると仮定すると、誰かがそれらを壊すインセンティブは、あなただけが使用するパラメーターを壊すのとほぼ同じですが、x週間ごとにのみ変更されます。
したがって、独自のパラメータを使用して、毎週ではなく変更するだけです。