2020年选择SSL证书(安全和CPU )的算法和密钥大小(使用nginx)

Question

我已经把这个问题贴在上面了，但是由于它不是一个真正的程序问题，所以我认为这也许是一个更好的问问题的地方：

我想设置一个新的SSL证书存储库，用于生成SSL证书(服务器证书(nginx)和客户端证书(linux/windows设备))。

我已经找了很长一段时间了，我不确定我是否完全理解。尤其是有些文章有几年的历史了。

许多文章只是谈论RSA，似乎推荐2048或3072，尽管提到2048年可能仍然是最好的选择( https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/ )。

例如，我发现了一篇文章( https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic-key-sizes-and-algorithm-recommendations )，但它似乎主要讨论密钥加密，就像@dave_thompson_085指出的那样

在“非对称(”公钥“)加密”一节中说明

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/ _试图促进ECC而不是RSA，但是在文章状态上评论说，如果量子计算机出现，ECC比RSA更不安全。在使用ECC时，这篇文章没有引用任何数字来说明性能的提高。

https://crypto.stackexchange.com/questions/1190/why-is-elliptic-curve-cryptography-not-widely-used-compared-to-rsa提到了潜在的法律问题和对被起诉的恐惧。

虽然CPU的使用不是一个主要的问题，但Id仍然想得到一些想法，因为我希望在类似覆盆子的设备上使用相同的CA和cert存储。

那么，服务器证书证书密钥算法和密钥大小的最佳选择是什么(不需要旧的internet资源管理器，但今天使用的个人计算机、平板电脑、移动电话)应该能够连接到服务器。

客户证书(不会在移动设备上使用)的最佳选择是什么？

我有点倾向于RSA 2048，但我真的不确定我是否正确地解释了所有的文章，不喜欢根据感觉做出选择。

Answer 1

在我老化的膝上型计算机(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的一个实现怪癖。国安局B套房让它比它应得的更受欢迎。

在TLS中，服务器执行“符号”，客户端执行“验证”，除非使用客户端证书，否则双方都会执行这两种操作(这很少使用，如果您使用这一点，您就知道您这样做了)。

EdDSA编号并不重要，因为尽管RFC存在，WebPKI将不使用EdDSA，当这些标准的HSM在标准本身退出之后，它们就会升级到PQCrypto。我想，对于自签名证书，您可以使用EdDSA (我没有尝试过，我不知道有什么支持它)。

您可以看到，服务器倾向于执行ECDSA NISP P-256签名，因为这些签名速度很快。客户希望验证RSA-2048或更高的RSA，而不是验证ECDSA，因为这是缓慢的。

在RSA和ECDSA之间的选择是您想要在服务器上还是在客户端上添加更多的负载。另外，有些人不喜欢ECDSA，而且可能有些客户太老了，无法处理ECDSA。

目前最受欢迎的选择是RSA-2048，没关系。

请注意，如果您只允许PFS密码套件(而且您应该这样做)，证书的密钥在证书过期时对攻击者毫无用处，因此它不需要几十年不间断。

您的ECDH是需要长期保持不变的部分，以防止对记录的流量进行追溯解密。

因此，如果你读到RSA-2048不再被认为是安全的，因为NSA可能很快就能破坏它，那么替换您的证书，您甚至对旧的流量也是很好的。但是，如果你读到X25519或P-256 ECDH不再被认为是安全的，因为NSA可能很快就能破解它--太晚了，他们已经拥有了那些原语保护您的TLS通信量的记录，在升级之后，您只保护未来的通信量，而不是旧的通信量。