2020年にSSL証明書（セキュリティとCPUに関して）に選択するアルゴリズムとキーサイズ（nginxを使用）
私はすでにこの質問をSOに投稿しましたが、これは実際にはprogramminの質問ではないので、ここで質問する方がよいと思いました。
SSL証明書（サーバー証明書（nginx）およびクライアント証明書（linux/windowsデバイス））を生成するための新しいSSL証明書ストアをセットアップしたい
私はすでにかなり長い間探していますが、完全に理解しているとは思いません。特に、いくつかの記事は数年前のものです。
RSAエンドに関する多くの記事は2048または3072を推奨しているようですが、2048が今日でもおそらく最良の選択であることを述べています（ https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/ ）
たとえば、1つの記事（ https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic-key-sizes-and-algorithm-recommendations ）を見つけましたが、それは@ dave_thompson_085がSOで指摘したように、主にキー暗号化について話します
「非対称（「公開鍵」）暗号化」のセクションに記載
Use, in order of preference:
X25519 (for which the key size never changes) then symmetric encryption.
ECDH with secp256r1 (for which the key size never changes) then symmetric encryption.
RSA with 2048-bit keys.
The security of a 256-bit elliptic curve cryptography key is about even with 3072-bit RSA.
Although many organizations are recommending migrating from 2048-bit RSA to 3072-bit RSA (or even 4096-bit RSA)
in the coming years, don't follow that recommendation. Instead migrate from RSA to elliptic curve cryptography,
and then breathe easy while you keep an eye out for post-quantum cryptography recommendations.
ただし、RSA 2048/3072/4048と比較したサーバーのCPU使用率への影響については触れられていません。また、楕円曲線アルゴリズムに切り替えることを提案する他の多くの記事も見つかりませんでした。
別の記事） https://www.thesslstore.com/blog/you-should-be-using-ecc-for-your-ssl-tls-certificates/ _ RSAの代わりにECCを宣伝しようとする、しかし、記事のコメントには、量子コンピュータが起動した場合、ECCはRSAよりも安全ではないというコメントがあります。また、ECCを使用するときに期待できるパフォーマンスの向上については、この記事には何も記載されていません。
https://crypto.stackexchange.com/questions/1190/why-is-elliptic-curve-cryptography-not-widely-used-compared-to-rsa 法的問題の可能性と存在の恐れについて言及訴えた。
CPU使用率は大きな問題ではありませんが、ラズベリーなどのデバイスでも同じCAと証明書ストアを使用したいので、まだいくつかのアイデアを得たいと思います。
したがって、今日の証明書キーアルゴリズムとサーバー証明書のキーサイズの最良の選択は何ですか（古いInternet Explorerは不要ですが、現在使用されているPC、タブレット、携帯電話はサーバーに接続できるはずです）
そして、クライアント証明書に最適なものは何ですか（モバイルデバイスでは使用されません）？
私は一種のRSA 2048を使う傾向がありますが、すべての記事を正しく解釈し、感情に基づいて選択するのが嫌いなのかどうかは本当にわかりません。
私の古いラップトップ（Skylake、openssl 1.1.1）のシングルコアのベンチマーク：
$ openssl speed rsa2048 rsa3072 rsa4096
sign verify sign/s verify/s
rsa 2048 bits 0.000662s 0.000020s 1510.2 49977.8
rsa 3072 bits 0.002078s 0.000040s 481.2 24920.9
rsa 4096 bits 0.004433s 0.000068s 225.6 14614.6
$ openssl speed ecdsap256 ecdsap384 ecdsap521
sign verify sign/s verify/s
256 bits ecdsa (nistp256) 0.0000s 0.0001s 37387.6 12823.3
384 bits ecdsa (nistp384) 0.0012s 0.0009s 855.6 1154.5
521 bits ecdsa (nistp521) 0.0003s 0.0007s 2881.8 1510.7
$ openssl speed ed25519 ed448
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0001s 21340.9 7981.1
456 bits EdDSA (Ed448) 0.0004s 0.0006s 2827.1 1599.6
独自のハードウェアと独自のバージョンのTLSライブラリでベンチマークを実行することをお勧めします（たとえば、IISのSChannelは異なるパフォーマンスになりますが、opensslは異なるマイクロアーキテクチャ用に最適化されたバージョンを機能として追加するため、ベンチマーク異なるopensslバージョンも）。
P-384は素晴らしい曲線ではありません。曲線パラメーターのため、P-521よりも遅く、opensslの実装の癖ではありません。 NSAスイートBは、それに値する以上に人気があります。
TLSでは、サーバーが「署名」を実行し、クライアントが「検証」を実行します。クライアント証明書が使用されない限り、両側が両方を実行します（これを使用する場合は、使用することがわかっているため、めったに使用されません）。
RFCは存在しますが、WebPKIはEdDSAを使用しないため、EdDSA番号は重要ではありません。これらの標準のHSMが廃止された後で、それらの標準のHSMが廃止されると、PQCryptoにアップグレードされます。自己署名証明書については、EdDSAを使用できると思います（私は試していません。これをサポートするものはわかりません）。
サーバーはECDSA NISP P-256署名を行うことを好むことがわかります。クライアントはRSA-2048以上のRSAを検証し、ECDSAを検証しないことを好みます。これは遅いためです。
RSAとECDSAのどちらを選択するかは、サーバーに負荷をかけるか、クライアントに負荷をかけるかです。また、一部の人々はECDSAを嫌い、一部のクライアントはECDSAを処理するには古すぎる可能性があります。
現在最も人気のある選択肢はRSA-2048であり、問題ありません。
PFS暗号スイートのみを許可する場合は（そうする必要があります）、証明書の有効期限が切れると、証明書のキーが攻撃者にとって役に立たなくなるため、何十年もの間壊れないようにする必要はありません。
ECDHは、記録されたトラフィックの遡及的な復号化を防止するために、長期間壊れないようにする必要がある部分です。
NSAはすぐにそれを破ることができる可能性があるため、RSA-2048はもはや安全とは見なされないことを読んだ場合、証明書を置き換えると、古いトラフィックでも問題ありません。しかし、それを読んだ場合X25519またはP-256 ECDHは、NSAで間もなく破壊される可能性があるため、安全であるとは見なされなくなりました。遅すぎると、アップグレード後に、これらのプリミティブによって保護されたTLSトラフィックのレコードがすでにあります。古いトラフィックではなく、将来のトラフィックのみを保護します。