当前使用 apache/mod_ssl，如果启用了 DHE，则将使用 1024 位临时密钥。我在Adam Langley 的博客中找到了以下引用：
理想情况下，DH 组将匹配或超过 RSA 密钥大小，但 1024 位 DHE 可以说比直接的 2048 位 RSA 更好，所以如果你愿意，你可以摆脱它。
因此，他似乎提倡DHE-RSA-AES256-SHA使用 1024 位临时 DH 密钥AES256-SHA而不是 2048 位 RSA 密钥。我的理解是 1024 位 DH（无论是否临时）的安全性与 1024 位 RSA 相当。他为什么会提出这样的建议？他那么重视 DHE 提供的前向保密吗？
这个问题有两个方面：
完美前向保密：通过使用“DHE”密码套件，您实际上可以根据 DH 私钥对数据进行加密，该私钥永远不会存储在任何磁盘上。对于任何给定的 SSL 会话，如果攻击者成功地对用于加密的公钥进行密码分析（DH 用于 DHE 密码套件，RSA 用于 RSA 密码套件），或者如果攻击者窃取了私钥的副本. 对于基于 RSA 的密码套件，后一种情况实际上更有可能发生。PFS 的重点是消除这种威胁。
RSA vs Diffie-Hellman：目前，破解 RSA 和 DH 的最著名方法需要分别解决两个难题，整数分解和离散对数。碰巧对于这两个问题，已知最快的算法是通用数域筛（虽然最初是一种分解算法，但 GNFS 的一个变体可以应用于离散对数）。对于渐近复杂度，因此当 DH 模量与 RSA 模量具有相同大小时，RSA 和 DH 具有相同的硬度。
然而，实际上，DH 有点难。GNFS 包括几个阶段，两个主要是筛子，然后是线性还原。对于大模数，由于矩阵的绝对大小，线性缩减成为瓶颈。对于给定的模数大小，您将在两个矩阵中获得相同数量的元素（一个用于 RSA，一个用于 DH），但矩阵元素在 RSA 情况下是简单的位，而在 DH 情况下是整数模p . 因此，DH 矩阵更大。
不过，它不会使n位 DH 像2n位 RSA那样“硬” 。如果我们查看记录，我们看到 RSA 为 768 位，DH 为 530 位；DH 案例使用较少的原始功率。此外，将 1024 位 DH 的硬度与 2048 位 RSA 的硬度进行比较并不完全合理，因为两者都处于“无法破解”区域。
所有这一切的总结如下：虽然 1024 位 DH 比 1024 位 RSA 稍强（理论上），但差异很小（例如，1024 位 DH 最多就像 1200 位 RSA）。但实际上，对于非临时密钥而言，私钥被盗的风险使任何 1024 位或更多位的 RSA 或 DH 的任何密码分析风险都相形见绌；从这个意义上说，PFS 是必不可少的，具有 1024 位 DH 密钥的 DHE比基于 RSA 的密码套件安全得多，无论 RSA 密钥大小如何。
同意 Tom Leek 所说的一切，但还有几点需要考虑：
最近的 mod_ssl 确实支持大于 1024 的 DH 参数，并且可以修补更旧的参数：http : //blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html（更新）
如果您需要（或希望）遵守美国政府的要求，NIST Special Pub 800-57（在 csrc.nist.gov）截至上个月要求基于整数的算法 RSA、DSA 和 DH 的最低要求为 2048（相对于 224 ECC 和哈希和 112 对称）。
如果您（可能）有 Java 客户端，那么（非常常见的）Suncle Java 和我相信（密切相关的）OpenJDK，通过当前的 7，不处理超过 1024 位的 DH。确切地说，它实现了 P 512 到 1024 x 64 和 Q 160 的原始 DSA (FIPS 186-0) 大小，而不是 FIPS 186-3 改进 2048/224,256 和 3072/256，并且没有充分的理由强加相同的限制在 DH 上。我看到一个 bugs.java.com 条目说这将在 Java 8 中修复，但谷歌没有找到它。另请参阅https://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception OTOH Suncle Java 7（如果您添加了 ECC 提供程序，则为 6）确实实现了 ECDH，并且默认情况下，ECDHE 套件优先于 DHE，因此，如果您的服务器同时支持 DH-2048 和 ECDH-reasonable，那没关系。（对于一般的 Web 客户端，ECDH P-256 似乎是最好的。）