编辑 2015 年 12 月 23 日星期三。:我对这个答案不满意了。虽然我仍然认为 8k DHParams 是错误的努力和过度杀伤（你最好使用EC DH），但我给出的解释是虚假的。现在变成了“社区维基”模式。将来可能会返工。下面是旧帖。

1）这是一个矫枉过正，现在4096就足够了吗？

一般来说，是的。我认为使该密钥长于证书中的密钥并没有多大用处。目前 8k 证书非常少见。2k或4k是常态。

一个密码套件使用了几个连接在一起的加密机制。（用于临时交换的公钥。证书的公钥。证书的哈希函数/MAC 函数。会话加密的哈希函数/MAC 函数。会话加密的对称密码学等）它们的工作原理类似于链。就像一条链条：它是最薄弱的环节。为加强非最薄弱环节所付出的任何努力都可能是浪费。

（现在组成密码套件的几个加密部分不能立即进行比较，但有一个粗略的共识。KeyLength.com 提供了一个计算器。）

（我认为甚至有一个词是“让每个链接都同样困难”的方法。但我现在不记得了。）

2) 我可以让 openssl dhparam 在多个内核上运行吗？

不知道。不要这么想。但我认为你也不需要。所以项目符号 1。

1. 它是不是有点矫枉过正，现在 4096 就足够了吗？

是的。即使是 2048 也足够了。

2. 我可以openssl dhparam在多个内核上运行吗？

该代码通过寻找随机安全素数来工作。您可以并行运行它多次，当一个完成时，您就可以设置参数。

1. 它是不是有点矫枉过正，现在 4096 就足够了吗？

取决于您的目标安全级别。8192 位 dhparam 大致相当于 192 位对称密钥加密。如果您想要 256 位级别的加密，那么 8192 位 dhparam 将太弱而无法满足该要求。如果您对 128 位加密没问题，那么 4096 位 dhparam 就足够了。

您可能需要查看Keylength页面，了解详细表格，其中包含来自不同组织的对称、离散对数和 ECC 算法的密钥长度建议。