IISにはどのSSLキーを作成する必要がありますか：RSAまたはDH？どのビット長が適切ですか？
IISサーバーのSSL証明書を作成しています。Microsoft RSA SChannel Cryptographic ProviderまたはMicrosoft DH SChannel Cryptographic Providerをいつ選択するかを知る必要があります。
質問1なぜ誰かが（DHの）レガシー証明書をまだ必要とするのでしょうか（私が想定しているもの）？
デフォルトがRSA/1024であることを考えると、これが最も安全な選択であると思います。もう1つはレガシーの理由によるものです。
質問2 xデバイスに適切なビットレベルを決定するためのガイドはありますか？
ラボの結果、数式、またはあなたの個人的な経験に興味があります。異なるビットレベルがSSLセッションを保護するために必要な時間に影響を与えることを知っています。これは、低電力デバイスにとって重要です。
質問ビット強度はこれらのシナリオにどのように影響しますか？
私の特定のケースはこれらのコミュニケーションパターンを含みます：
セッションを頻繁に接続および切断する強力なクライアントがあるWebサイト
高い持続時間を維持するWCF WebサイトIOデータ転送
IPhoneおよびデスクトップ向けのクライアント向けWebサイト
RSAとDiffie-Hellman（DH）は、同様の目標を達成する2つの異なるアルゴリズムにすぎません。ほとんどの目的で、あるアルゴリズムを別のアルゴリズムよりも優先するという圧倒的な理由はありません（RSA対Diffie-Hellman）。パフォーマンス特性は多少異なります。 RSAは標準的な選択であり、それはすばらしい選択です。
これはサイトのセキュリティニーズに依存している可能性が高く、キーサイズがパフォーマンスに影響を与えるため、キーサイズについて万能の推奨を与えることは困難です。私のデフォルトの推奨事項は、1536ビットのRSAキーを使用することです。 1024ビットのRSAキーは最低限必要です。ただし、1024ビットのRSAキーは、短期的にはクラック可能になる可能性のあるものの端にあり、一般に最近の使用には推奨されないため、可能であれば、1536ビットまたは2048ビットのRSAキーをお勧めします。
2010年12月31日の時点で、多くのCAが1024ビットエンドエンティティ証明書のサポートを最近開始していることに注意してください。問い合わせると、レガシー目的で1024ビットRSAキーの証明書を発行する可能性がありますが、人々に推奨しています。 2048ビットRSAに移行します。一部のCAは、例外なく2048ビットのキーを必要とします。個人的には、2048ビットのRSAはほとんどの目的にとって過剰であり、1536ビットのRSAはおそらく問題ないと思いますが、2048ビットのRSAはある程度の慣性を蓄積しています。
キーが大きいほど、初期接続の確立が遅くなります。サーバーは、サーバーに接続する新しいデバイスごとに（24時間以内に）いくつかの公開キー操作を実行する必要があるため、サーバーの負荷に最も影響します。公開鍵暗号化では、接続が作成されたときに1回だけ支払われる1回限りのコストのみが発生します（約24時間以内に新しい接続に対して再度支払われることはありません）。接続を介して転送されるデータの量は関係ありません。
したがって、私のデフォルトの提案は次のとおりです。1536ビットのRSAキーを選択し、通常のローエンドクライアント（iPhoneなど）でテストしてパフォーマンスに問題がないことを確認し、サーバーで接続数を処理できるかどうかをテストします。その鍵サイズに関連付けられた日。サーバーのパフォーマンスに問題がある場合は、サーバーのパフォーマンスを高速化するための暗号アクセラレーターを検討してください。それでも深刻なパフォーマンスの問題がある場合は、1024ビットのRSAにドロップダウンすることを検討できます。銀行サイトなど、セキュリティが重要なサイトがある場合は、2048ビットのRSAを使用します。
DHとRSAは異なる公開鍵アルゴリズムですが、公開鍵のサイズが等しい場合、セキュリティに大きな違いはありません。 DH certificatesは非常に一般的ではないので、心配する必要はありません。
RSA操作を実行するために必要な時間は、係数サイズの立方体、つまり2048ビットの鍵の方が1024ビットの鍵よりも約8倍遅いため、ほぼ増加します。 RSA公開操作（復号化、署名）はプライベート操作（暗号化、検証）よりもはるかに高速であり、クライアントはほとんどの暗号スイートでサーバーの公開鍵を使用して公開RSA暗号化を実行するだけでよいため、これは主にSSLでのサーバーのパフォーマンスに影響します。
最初のケースでは、SSLセッション再開の使用がパフォーマンスに強く影響します。クライアントがSSLを使用して同じサーバーに再接続する場合、前のセッションを「再開」するオプションがあり、高価なRSA鍵交換をスキップできます。 2番目のケースでは、SSLのアプリケーションデータはサーバーのRSAキーではなく対称暗号で暗号化されるため、長期間の転送はサーバーのキーサイズの影響をまったく受けません。 3番目のケースについては、上記の（2）を参照してください。
このページには、パフォーマンスに対するキーサイズの影響を示すいくつかの興味深いベンチマークがあります。 https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/
- 私はDiffie-Hellman（DH）の選択がlegacyであるとは信じていません。これは、時代遅れで置き換えられたことを意味し、あまり使用されません。私の意見では、これは、証明書要求を行うときに暗号化サービスプロバイダーを選択するときに、ドロップダウンの最初のものではないためです。しかし、誰かが自分の選択をするときに実際に宿題をしている場合でも、DHを選択することはおそらくないでしょう。 Microsoftによると、どちらか一方を選択する理由は、次のとおりです。
「安全でないネットワークを介して秘密鍵を交換する必要があり、以前に相手と通信したことがない場合は、Microsoft DH SChannel Cryptographic Providerを選択してください。」
私にとって、これはRSAを使用することにもつながります。通常、セキュリティで保護されていないネットワークを介してキーを交換することはありません。イントラネット（自己署名の場合）または暗号化された電子メールを使用して、キーを認証局に渡します。サードパーティプロバイダーの証明書発行サイトと通信するときにSSLを介して。なぜあなたがそれを必要としないときに、より豪華な/非標準的なものを手に入れるのですか？
- 3.私の個人的な経験は、ビット長が長い場合、通信の暗号化を解除するためにより多くの処理時間/速度/パワーが必要です。つまり、サーバーの負荷が高くなり、処理中にメモリバッファーが詰まったり、CPU/RAMが急上昇したりする可能性が高くなります。これと、安全な通信の必要性とのバランスを取る必要があります。一般に、ハードウェアが処理できる最大のビット長を取得する必要があります。これは通常、組織に必要なセキュリティの機能になります。つまり、一般的に銀行、金融機関、政府機関などは、ある種の資金をより多く引き出します。情報の機密性のため、より長いビット長（2048+）をサポートするために必要なハードウェア。ただし、2048を超えると、標準の既製のサーバーハードウェア、つまり、オペレーティングシステムビルダーがサーバーOSの実行を推奨する最小動作仕様で構築されたサーバーのパフォーマンスが低下する可能性があります。私の経験では、デュアルコアプロセッサ（4 GB RAM）に比べると、2048を超えるビット長でサイトを開始しただけでも問題が発生します。
そしてもちろん、ビット長と仕様を、予想されるユーザーベースと同時接続に対してバランスをとる必要があります。
Concurrent Connections = Number of Sessions Per Hour x Average Session Duration (in seconds) / 3,600
この数値と必要なCPU GHzの直接的な相関関係はわかりません。これは、CPUアーキテクチャ、キャッシュ/バッファサイズ、FSB、製造元に応じて異なる可能性があるため、これを遵守したい標準の比率として存在する場合（AMD vs. Intel）などですが、数値が大きいほど、RAM CPUのパフォーマンスが低下しないようにする必要があり、CPUの速度が速いことは明らかです。需要に対応する必要があります。明らかに、提供されるデータの量がこの要因に寄与します。これが提供されるまでにかかる時間はlatencyと呼ばれ、レイテンシは短くなります（より高速な内部ネットワーク）とより多くのデータが送信されている場合、必要に応じて動作（読み取り、暗号化）するのに十分でないと、SSLを介して処理するにはCPUが速すぎて多すぎる可能性があります。
質問3の個別の質問について：
- セッションを頻繁に接続および切断する強力なクライアントがあるWebサイト
これはサーバー側の暗号化の増加に影響を与えますが、SSLに関する限り、切断コストは実際には何もありません。これは、ライトスイッチが遮断されているようなものです。これは、同時に接続を開始する接続の数に戻ります。接続の開始時にCPUとRAM=使用状況を監視し、それがプロセスモニターでそれらを急上昇させている場合は、ビット長を短くするか、リソースを増やすか、またはその両方を行う必要があるかもしれません。
- 高い持続時間を維持するWCF WebサイトIOデータ転送
これは依存します-転送は、背後に大量のデータを含む単一の要求ですか、それとも小さなパケットを含む多くの転送ですか？前者は通常、後者よりもCPU/RAMで簡単です。また、帯域幅については、暗号化処理よりも多く話しています。それは、SSL暗号化/復号化による処理能力よりもボトルネックになる可能性が高いためです。
- IPhoneおよびデスクトップ向けのクライアント向けWebサイト
電話を話している場合は、4G接続を話していることになります。これは、2048以下で話している限り、ビットを解読する処理能力よりもボトルネックになる可能性があります。携帯電話向けのサイトでは、プログラマーの価値がある場合、グラフィックスやデータが少なくなるので、暗号化して転送する必要はほとんどありません。デスクトップは通常ネットワークに固定されており、（一般的に）電話よりも処理能力が高いため、デスクトップ用のサイトは別の動物です。サーバーの場合、SSL暗号化ビットを処理/提供するのは、CPU/RAMとビット長の違いであり、モバイルギアサイトと標準サイトの違いは異なります。モバイルギアのサイトでは、（理論的には）暗号化するビットが少ないため、処理能力が低くなり、ビット長が長くなります。完全なデスクトップギアのサイトには、逆のことが当てはまります。