dhキーの長さがtlsのrsa長と一致する必要があるのはなぜですか？
いくつかのソースは、DHキー長（素数のビット）がTLSのrsaのキー長と一致する必要があると述べています。たとえば、opensslのSSL_set_tmp_dh（3）には、使用されているキーにdhパラメータを一致させる方法のサンプルコードがあります。
明らかに、DHがチェーンの中で最も弱いリンクになりたくありません。もちろん、AES-256を使用し、DH-512との鍵交換のみを保護するのは愚かです。
キー長を一致させる他の理由はありますか？特に、プロトコルにこれを必要とするものはありますか？
当然の質問は次のとおりです。私が常にDH-2048を使用している場合（および他のすべてが比較的安全か弱い）、これは何か（おそらくパフォーマンスを除く）に悪影響を与えますか？
「DHE_RSA」暗号スイートでは、セキュリティはDiffie-Hellmanによって提供されるものとRSAによって提供されるものの両方に相対的です。 「一般的に」、全体的なセキュリティは2つのうち最も弱いものになります。そう：
- dHキーがRSAキーよりも弱いと、全体的なセキュリティが低下します（RSAキーだけの場合と比較して）。
- dHキーがRSAキーよりも強力な場合、実際の追加のセキュリティは得られないため（RSAキーの制限による）、有害ですが、それでも、余分な大きなキー（大きいメッセージ、高い計算コスト、および限られたクライアントとの相互運用性の喪失）。
DHとRSAが同様のサイズのキーで使用された場合、DHとRSAは同様の強度を提供するように思われます。つまり、1024ビットの素数を法とするDHは、1024ビットのモジュラスを使用したRSAと同じくらい強いと言えます（ただし、素数ではありません）。もちろん、係数）。したがって、これにより、DH鍵とRSA鍵は同じ長さでなければならないという規則が得られます。
詳細を見ると、物事はあまり明確ではありません：
DHE_RSA暗号スイートでは、DHとRSAは異なる目的で使用されます。 RSAはsignature用であり、そのセキュリティターゲットは現在に限定されています。今日、SSL接続を行うとします。攻撃者はそれを記録します。それから彼は接続を壊すために出発します。 5年後の広範な計算とテクノロジーの向上により、攻撃者はDHキーを破ることに成功しました。攻撃者は、記録された接続を解読して秘密を知ることができます。ただし、攻撃者がDHに集中する代わりに、サーバーのRSAキーを破ったと仮定します。その後、攻撃者は...何も持っていません！ RSAキーを破ると、将来の接続のためにサーバーに偽装する権限が与えられますが、過去の接続の復号化には少し役立ちません。その間、サーバーの証明書を少なくとも1〜2回、毎回新しいキーで更新したため、攻撃者の努力はすべて無駄になりました。
このため、「DHE_RSA」暗号スイートにおけるRSAのセキュリティとDHのセキュリティを簡単に比較することはできません。これらのスコープやターゲットレベルは同じではなく、全体として、RSAのセキュリティはDHのセキュリティほど重要ではありません。
DHとRSAは、大まかな意味でのみ同じモジュラス長に対して同等のセキュリティを備えています。 RSAを解くための既知の最適なアルゴリズムは General Number Field Sieve であり、DHを解くための既知の最適なアルゴリズムもGNFSです。ただし、大きな係数（たとえば、1024ビット以上）の場合、GNFSのボトルネックは「線形代数」フェーズであり、これはアルゴリズムの最後です。これは、非常に重要なサイズの行列に対する数学的に重要な計算です。これは、並列計算が非常に難しく、非常に高速な大量のRAMを搭載したマシンが必要です。実際、1024ビットのRSAまたはDHに対応できる既存のコンピューターはありません（専用のマシンは、物理法則を破ることなく想定できますが、かなりの費用がかかります）。
DHを壊すGNFSバリアントは同じ線形代数ステップを持っていますが、「より大きい」行列があることがわかります。より多くの要素はありませんが、要素は単なるビットではなく整数モジュロp（素数係数）になりました。これは、DHを解読するための行列が、RSAを解読するための行列と同様のキーサイズで（概念的に）1000倍大きいことを意味します。これは、実際には、1024ビットDHは1024ビットRSAよりも壊れにくいことを意味します。
（また、実際には、1024ビットのDHと1024ビットのRSAは現在の経済技術のコンテキスト内で壊れていないので、堅牢性の比較は塩の粒度で検討する必要があります。アルゴリズムは壊れていないよりも壊れにくいということはありません。）
必ずしも希望どおりにDH係数を選択できるわけではありません。さまざまな歴史的な理由により、既存の実装は制限される場合があります。一部のクライアントは、2048ビットのRSA鍵に問題がなくても、1024ビットより長いDH係数の使用に問題がある可能性があります。堅牢性とセキュリティバランスの平等はすばらしいことですが、それでもデータは流れなければなりません。接続の確立の失敗は非常に安全ですが、あまり役に立ちません。
したがって、体系的な2048ビットのDHモジュラスはセキュリティに害を及ぼすことはなく、適度なオーバーヘッドしか発生しません（1024ビットのDHを超えると、フルハンドシェイクごとに250から500バイトが追加され、CPUが追加されますが、重要ではありません）。 、それは可能性があります既存の古いクライアントとの互換性を損なうため、これはテストを必要とします。少なくとも、 標準 の観点からは、混在に関与するRSAキーのサイズに関係なく、2048ビットDHで十分です。
「明らかに、DHがチェーンの中で最も弱いリンクになりたくない。もちろん、AES-256を使用して、DH-512で鍵交換を保護するだけでは、ばかげている。」丁度。 DHとRSAは異なりますが、ブルートフォースに最も効果的なアルゴリズムは同じです（トムリークスの回答を参照）。したがって、セキュリティレベルは類似しています。 （DHは実際には少し強力です。）DHパラメーターとRSAキーを同じサイズにすることは明らかなことです。
「キー長を一致させる他の理由はありますか？」いいえ、しかしあなたはすでにあらゆる理由を持っています。
「特に、プロトコルに何か必要なことはありますか？」いいえ、一致しません。好きなことができます。 TLSは関係ありません。実際、 manywebsites は2048ビットのRSAキーを使用しますが、残念ながら1024ビットのDHを使用しています。 （ついに、Apacheが最近これを修正しました。）
「私が常にDH-2048を使用している場合（および他のすべてが比較的安全であるか、それよりも弱い場合）、これは何か（おそらくパフォーマンスを除いて）を傷つけますか？」まあ、安全な構成では、他のすべては比較的安全（RSA）またはstronger（AES）になります。弱いものを使用している場合は、停止する必要があります。 :-)しかし、あなたの質問に答えるために、それは大丈夫だと思います。
パフォーマンスに関しては、ほとんどのクライアントがECDHEをサポートしています 非PFSキー交換よりも遅くはありません 。クラシックDHEは大幅に遅くなり、パラメーターのサイズが大きくなると悪化しますが、ほとんどのクライアントがSSLとSSLを使用しない場合、大きな違いはありません。ターミネーターが過負荷で実行されていません。
一部のクライアント-ほとんどJava-は、1024ビットより大きいDHパラメータと互換性がないことに注意してください。クライアントとの互換性が絶対に必要な場合は、セキュリティを犠牲にして1024-まだ安全なビットDHかろうじてです。ただし、別の方法で問題を解決した方がよいでしょう。新しいJavaバージョンは、たとえばECDHEをサポートしています。
編集：CodesInChaosとTom Leekの指摘によると、RSAキーは、証明書の有効期限が切れるまで1〜2年間のみ安全である必要があり、それを解読すると偽装できるだけですが、DHキーは何十年もの間安全である必要があります。データが復号化されても、もう気にしないvery良い。おそらく私が言ったことよりも重要なので、ここにコピーアンドペーストします。 :-D
編集：ちなみに、2048ビットを超過しないように注意します。あなたはあまり研究されていないクライアント互換性問題の領域に入ります。たとえば、Firefoxは（実際には）約2200ビットの制限がありました。 （おそらく、GnuTLSコミュニティーに質問することもできます。彼らには、異常に大きなDHの経験があります。）