Certbot: 默认 RSA 密钥位长应为 3072

我什至会建议 4096（我几乎在所有系统上都这样做）。

谢谢，
马丁

我也建议4096。

但几个月前，他们默认不同意 4096： https ://github.com/letsencrypt/letsencrypt/issues/489

与默认情况下根本没有安全性相比，我更喜欢折衷方案（= 具有 3072 位模数的 RSA）。

也建议4096。
安全性必须通过设计和默认设置良好：没有标准用户更改默认配置。

对于 2048/3072 与 4096 位（只有非常小的速度开销），没有可接受的论据。
如果用户代理硬编码某些密钥大小（2048 和 4096 位将比 3072 更好地支持），3072 位可能会导致兼容性问题。

最糟糕的是，90 天密钥重新生成以证明 2048 位密钥使用的论点并不好：

• 密钥再生破坏了许多其他 TLS 堆栈保护，例如 DANE/TLSA 或 HPKP，强化配置必须禁用它以避免大麻烦。
• 钥匙再生并不是说“破坏过去”。 如果 Web 服务器没有正确配置仅 PFS 密码套件，则类似 NSA 的机构可以拦截和存储受 2048 位密钥保护的网络通信，并且可以在 20 或 30 年内解密它们，即使相应的密钥被破坏。 4096 位密钥保护更长的非 PFS 通信。
• 即使仅使用 PFS 密码，Web 服务器通常也将协商的 DH 参数基于私钥大小。 如果您仅使用 2048 位私钥，则您的 DH 参数仅为 2048 位，因此可能对 LogJam 较弱。

4096 的另一个 +1，这就是我这些天一直使用的。

有关此问题的大量讨论，请参见 #489。

用LE的默认设置，RSA 2048位，90天，试试破解吗？ 我建议关闭这个问题。

问题不是“证明你可以破解它”（或保持在 1024 位，从现在开始没有人破解它）而是“所有推荐/最先进的技术要求至少 3072 位”（NSA、NIST、ANSSI、FIPS、Qualys 和更多的）。
默认情况下升级到 4096 位没有有效的缺点。

（我再说一遍，即使有 90 天的密钥更新，如果不使用 PFS，即使技术有效性只有 90 天，您也有数十年的实际密钥有效期，而且 90 天的密钥更新打破了许多其他 TLS 堆栈（TLSA， HPKP，证书固定），所以理智的系统管理员必须禁用它并在实践中重复使用密钥至少 120 天和 1 年）

然而，在 Alexa 排名前 1,000,000 的网站中，超过 89% 启用 SSL/TLS 的网站使用 RSA 2048 位，包括许多在线银行网站。

是的，如果你想要的话，银行也有 SSLv3 和 MD5 https://imirhil.fr/tls/#Banques %20en%20ligne
还有谷歌/Youtube https://imirhil.fr/tls/alexa.html
色情网站根本没有 TLS https://imirhil.fr/tls/porn.html
甚至 CA 也有 SSLv3、MD5、RC4 或 SSLv2（是的，你没看错……）和 40 位 EXPORT 套件https://imirhil.fr/tls/ca.html

TLS 配置在野外非常糟糕，这不是继续做废话的请求。

@devnsec-com 所以它们不安全。 即使 IPv6 和 DNSSEC 是很好的技术，它们还没有大规模部署。 RSA 4096 位也是如此。 我们必须前进而不是踩水。

使用 RSA 3072 或 4096（甚至更长）的唯一原因是面向未来，但如果证书只有 90 天，那么所有用户是否真的需要默认长于 2048 的 RSA？ 如果您真的很偏执，请选择更长的键，有一个参数，您可以更改它。

默认情况下，所有用户都需要 3072+ 密钥。

真正知道自己在做什么的人最终可以减小大小，但默认情况下，Let's encrypt 必须提供最先进的兼容配置。
标准用户（实际上是 99%）甚至不查看配置或关心生成的密钥的大小，甚至不知道 TLS 到底是什么……

请记住，我们谈论的是 SSL/TLS 证书，您可以在您的服务器上支持 PFS，并且可以在必要时撤销它。 我们不是在谈论可以使用 20 年甚至更长时间的 OpenGPG 密钥或 SSH 密钥。

多年后，当 RSA 2048 实际上被证明不再安全时，我们可以将 LE 默认更改为 RSA 4096，几乎所有用户将在 90 天内更改为 RSA 4096。

既然我提到了 OpenGPG，我想说即使是 OpenGPG 也默认为 RSA 2048。
阅读： https ://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

你可以。 你也可以没有 PFS。 如果 2048 位密钥，你不安全。 即使续订90天。 如果没有 PFS，密钥销毁是没有用的，你的数据已经存在，应该在几十年内解密。

并且只能撤销证书，不能撤销密钥。
密钥与 GPG/SSH 密钥完全相同：生成后，您必须处理它们，直到 PFS 对地球表面造成物理破坏，如果没有 PFS，则永久处理。

既然我提到了 OpenGPG，我想说即使是 OpenGPG 也默认为 RSA 2048。

GPG 使用 4096 密钥确实有缺点（只有少数智能卡支持超过 2048，移动设备……）。 在 TLS 上，没有。

在 GPG 上，目前每个人都生成 4096 位密钥，所有教程和建议都要求它。

您刚刚提出了一个观点，而不是争论默认为 RSA 2048 或更长，我们应该谈论默认启用 PFS。 因为无论密钥有多长，它迟早都会被解密，RSA 2048 会，RSA 4096 也会。

是的，但是您无法使用 Let's Encrypt 确保 PFS（更糟糕的是，只有PFS 密码，您可以协商 PFS 密码套件，但服务器可以支持 no-PFS 或 EXPORT……）。

目前，仅使用 PFS 密码套件存在主要缺点（浏览器兼容性，请参阅 https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA）。

在所有情况下，这都不是 CA 的工作。

我们这里说的不是 CA，而是客户端软件，对吧？

不，TLS 非常复杂，有很多堆栈。
没有软件可以完全处理它。

您无法猜测您的用户是否有 DNSSec 或 TLSA，必须确保 IE 兼容性或非标准用户代理，使用什么版本的 OpenSSL 等等。
LE 唯一能做的就是提高密钥大小……

不，当 LE 默认使用 RSA 3072 或 4096 时，有人会说他希望所有用户都默认使用 RSA 8192，这是一场无休止的军备竞赛。

@devnsec-com 不。NSA、NIST、ANSSI、FIPS、Qualys 不推荐 RSA 8192，但至少 RSA 3072。

不，如果有人要 8192，您可以说 4096 目前是安全的，并且在任何地方都推荐使用。
目前，这不是 2048 年的情况。

我也可以说Yubico 、 Cisco和许多公司在我们发言时都在推荐 RSA 2048。

密钥长度越长越安全，但商业公司在这个话题上更加务实。 同样，在当前阶段默认 RSA 2048 就足够了，只要我们在需要时支持更长的密钥。

这个对话的好资源 - keylength.com

@devnsec-com Yubico 和 Cisco 的立场是有效的，因为它们存在硬件问题（HSM、PKI 和智能卡不太支持 4096 位）。

来自 Yubico：«这不是 Yubico 的限制，而是 YubiKeys 中使用的 NXP A700x 芯片的硬件限制»
来自 Cisco：4096 位仅适用于 Cisco IOS XE 版本 2.4（并且硬件难以升级），并且给定的页面非常旧（自 2.4 版本（2009 年）以来似乎没有更新，自至少 2.X 版本以来的默认值相同……）。

这并不是因为所有其他羊都向悬崖奔跑，我们必须跟随它们……

@devnsec-com 我还补充说，思科文档是关于 PKI 和 CA 管理的，在这个领域（CA 证书，而不是最终用户证书），CA/B-forum建议至少 2048 bits 。

自 2014 年以来，内部也存在关于 4096 个内含物的争论。

我们会包括关于密钥大小的建议吗？ 有些人故意要使用 4096 位密钥。 他们会接受建议吗？ 该文档可以解释安全性、兼容性和其他因素之间的权衡

但似乎硬件路由器不支持超过 2048 的根（思科）

Iñigo 说思科的最新产品不支持 SHA-1 和 4096 位根。 Kelvin 说他可以尝试与思科合作来改变这种状况。

@devnsec-com 另一个关于 CA/B 论坛的内部评论。

为下一组更改设置目标日期以提高安全性/性能 (RSA-4096/ECC/SHA-512/etc)

大家好， 让这个线程继续下去并听取 LE 工作人员的回复会很棒。
据我所知， @aeris 的论点似乎是有效的，并不矛盾。 除非我们错过了什么，我还希望 LE 很快将默认 RSA 密钥切换到 4096 位。

默认情况下为 RSA 3072 位 +1。

如前所述，RSA 2048bit 仅相当于 112bits 的对称密钥保护。 这低于当今广泛使用的最低 128 位。 RSA 3072 位仅相当于 128 位，因此足以满足目前的需求（以及 NSA 于 2016 年 1 月推荐的最低要求）。

请注意，以前对密钥大小的所有寿命估计都应持健康的怀疑态度，因为它们通常假设密钥破坏的线性改进，但新的攻击可能会更快地降低安全性。

大于 2048 位的 RSA 密钥目前与 Amazon Web Services 不兼容。 来自Amazon CloudFront 开发人员指南：

SSL/TLS 证书中公钥的最大长度为 2048 位

只是想我会在对话中添加这个额外的点。

任何希望拥有超过 2048 位 RSA 的人都可以简单地输入--rsa-key-size 3072或--rsa-key-size 4096来请求这些密钥大小。
请注意，生成较大的 RSA 密钥所需的时间会呈指数级增长，任何大于 4096 的密钥都可能导致旧版 Apple 浏览器崩溃。

实施#2632 后，性能缺陷对大多数人几乎没有影响。
因此，我们可以将 EC 256 与 3072 RSA（或我们喜欢的任何默认值）结合起来，为两者提供相同的强度。

顺便说一句，作为支持 EC 密钥的建议，使用--ec-key-type之类的命令来生成 EC 密钥并请求证书。
我目前使用 certbot 生成并签署了我的 RSA 密钥，并使用 shell 脚本生成了我的 EC 密钥。

@WilliamFeely那是 #2625

谢谢。
至于 RSA 密钥大小，我猜 RSA 2048 仍然是行业标准，并且仍然授权 PCI-DSS 合规性，因此为什么它仍然是默认值？

以下是最新的 PCI-DSS 文档（ v3.2，2016 年 4 月）所说的：

有关强加密和安全协议（例如 NIST SP 800-52 和 SP 800-57、OWASP 等）的信息，请参阅行业标准和最佳实践。

幸运的是，词汇表将强密码学定义如下：

密码学基于经过行业测试和接受的算法，以及提供至少 112 位有效密钥强度和适当密钥管理实践的密钥长度。 密码学是一种保护数据的方法，包括加密（可逆）和散列（“单向”；即不可逆）。 请参阅散列。

在发布时，经过行业测试和接受的标准和算法的示例包括 AES（128 位和更高）、TDES/TDEA（三倍长度密钥）、RSA（2048 位和更高）、ECC（224 位和更高） , 和 DSA/DH（2048/224 位及更高位）。 有关加密密钥强度和算法的更多指导，请参阅当前版本的 NIST 特别出版物 800-57 第 1 部分 (http://csrc.nist.gov/publications/)。

_注意：以上示例适用于持卡人数据的持久存储。 PCI PIN 和 PTS 中定义的基于交易的操作的最低加密要求更加灵活，因为有额外的控制措施来降低暴露水平。
建议所有新实现使用至少 128 位的有效密钥强度。_

对于与 Web 服务器一起使用的 RSA 密钥，无需默认为 3072。

首先，您应该只使用提供 FS 的密码。 这样，即使您的私钥后来被发现，过去记录的会话仍然是安全的。

对于像 GnuPG 这样的东西，您可能想要使用更大的（我使用 4096），因为 FS 不是一个选项，客户端和服务器在建立连接时不会协商自己的密钥。 即使使用 GnuPG，您也确实不需要 > 2048，如果您这样做，EC 会物超所值，但由于它还没有得到客户很好的支持，而且 GnuPG 加密的消息可能在几十年内都是敏感的，所以 4096 至少是正当的，

如果使用 FS，则使用 HTTPS 是不合理的。 使用 FS 时，应尽可能使用 ECDHE 密码，以便它们在客户端和服务器之间使用的密钥更强。 如果您的服务器仍然支持 DHE 密钥，那么您应该担心 DH 组有多少位，并且大多数人使用 RFC 中发布的预定义 2048 DH 组。 生成自己的 2048 位 DHE 组是合理的。

服务端私钥，2048位不容易破解，足够了。 建议默认值 3072 或 4096 就像建议使用 20 磅镇纸而不是 15 磅。 是的，20 磅重，但没有真正的好处，而且您的 2048 位 RSA 密钥将在它不再安全之前被替换很久很久。

始终使用前向保密并尽可能使用 ECDHE 密码。 私钥 RSA 2048 已经足够好了，如果您真的想要更好，请使用 ECDSA 而不是 RSA 作为密钥。

我想我想说的是，如果我错了，请纠正我，当你的 TLS 需要使用前向保密的密码时，服务器长期私钥的唯一真正目的是身份。

客户端和服务器之间发生的实际加密使用客户端和服务器之间协商的临时密钥，该密钥与 x.509 证书使用的密钥无关。

这就是您需要担心的，永远不要使用 < 2048 的 DH 参数，最好使用 ECDHE。 然后，服务器的私钥只与建立服务器的身份相关，而 2048 位 RSA 肯定足够好，特别是如果您遵循最佳实践每年至少生成一次新密钥。

因此这个问题应该被关闭，并且对安全性的重视应该放在正确的密码套件选择上。

很有趣，但是当 Applebaum 和 Snowden 都建议我使用 4096 位的 RSA 密钥时，嗯，嗯，我不知道，我想我可能会遵循这个建议。 身份不正是我们在这里试图隐藏/保护的吗？

@jult坚持使用 4096 位，尤其是在您使用 GnuPG 时。 直到每个人都升级到 2.1，我们才能访问 ed25519 OpenPGP 密钥。 他们并没有那么强大。 （我很喜欢我的 ed25519 SSH + GPG 密钥，所以请鼓励大家远离 RSA！）

预计在未来几年左右，拥有大量计算资源的攻击者可以破解 2048 位 RSA 密钥。 768-1024 位已经经常损坏。

我不认为 3072 是一个合理的默认值，它有点与众不同。

2030 年以后不会推荐 2048 位，我向你保证，日落会像 SHA-1 一样是渐进的。 我已经阅读了很多政府标准文件之类的......

有一段时间，人们一直在练习制作 8192 位及以上的密钥……这只是对源代码进行了有趣的两行或三行更改，但我不确定它们与其他人的可操作性如何。

. @WikiLeaks发布了一个异常强大的 8192 位 RSA PGP 加密密钥用于提交https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

——KM Gallagher (@ageis) 2015 年 5 月 27 日

@ageis此外，对 16384 有相当严格的限制。它需要 * 很多 * 更多的黑客攻击才能变得更大； 我试过。

— isis agora lovecruft (@isislovecruft) 2014 年 9 月 8 日

@jult我不会谈论 Appelbaum 和斯诺登的事情。 我对他们也很熟悉，但我认为这是一种摇滚明星对你正在制作的权威的吸引力。 查看所有来源，我可以特别推荐一些：

• http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
• https://pages.nist.gov/800-63-3/sp800-63b.html
• http://www.secg.org/sec2-v2.pdf
• http://www.ecc-brainpool.org/download/Domain-parameters.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf
• https://safecurves.cr.yp.to/

就个人而言，我更热衷于让每个人都更新到 GnuPG 2.1，具有更快的 kbx 格式，并生成新的 ed25519 密钥（想法@dkg或@floodyberry？），我希望下一个 Yubico 系列将支持它们。 事实上，我可以伸手检查； 正如我对 YubiKey 4 进行了一些 beta 测试一样。我不喜欢密钥必须如何保护/密码才能导出，因为它使导入智能卡成为一项挑战。

当我谈到这个问题时，我将从 NIST 特别出版物 800-57 中删除一张很棒的图表。 更多是从哪里来的。 星期六晚上开始的完美事情，是吧？

同样，客户端握手期间的额外大小负载不值得使用较小的密钥大小来承担额外的风险。 那些建议反对使用 4096 位 RSA 的人未能提出不这样做的有效论据。 更不用说我们依赖于正确生成密钥这一事实，如果最终出现缺陷，我们最好使用 4096 位密钥。
检查这个； https://github.com/certbot/certbot/issues/489#issuecomment-114083162
您要确保生成 >=4096 位的 Diffie Helman 密钥，像这样
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
如果您希望在密码套件中启用 DH(E) 时它有意义。

我刚才为 RSA 签名运行了一个综合基准测试并看到了这个：

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

第一个数字是模数大小，第二个数字是每个签名操作所需的平均秒数。

我发现@AliceWonderMiscreations关于前向保密的评论有些说服力； 有没有人碰巧有一些关于今天与各种密码套件协商的 TLS 连接分数的当前统计数据？ 如果现在很少有人使用非 PFS 密码，那么 RSA 密钥长度参数将具有最小的长期安全后果。

FS 和非 FS 是一个单独的问题。 是的，我们应该鼓励 FS 密码套件，并且客户端和服务器都应该在他们知道有可能的情况下禁用非 FS 密码套件。 （TLS 1.3 没有剩下的非 FS 密码套件，耶！）这并不意味着我们应该忽略强加密身份密钥的重要性，或者我们应该相互竞争。 请记住，伪造的身份密钥使 MiTM 甚至 FS 连接成为可能。

RSA 3072 似乎是推荐（如 ENISA 和 NIST）在未来十年内使用的密钥的强大安全边际的最佳选择。

嗨@dkg ，

FS 和非 FS 是一个单独的问题。 是的，我们应该鼓励 FS 密码套件，并且客户端和服务器都应该在他们知道有可能的情况下禁用非 FS 密码套件。 （TLS 1.3 没有剩下的非 FS 密码套件，耶！）这并不意味着我们应该忽略强加密身份密钥的重要性，或者我们应该相互竞争。 请记住，伪造的身份密钥使 MiTM 甚至 FS 连接成为可能。

在默认情况下，我们目前仅使用单个 RSA 主题密钥 60 天（活动 MITM 风险在证书的 90 天生命周期内持续存在），然后切换到另一个。 似乎“可以在 90 天内破解 2048 位密钥的攻击者可以执行主动攻击”和“可以随时破解 2048 位密钥的攻击者可以恢复旧会话的明文”之间存在相当大的差异它参与了”。 在 FS 密码套件的情况下，前者是正确的，而后者不是正确的。

关于密钥长度的建议通常似乎假设一个威胁模型，其中攻击者在使用该密钥一段时间后破坏该密钥 - 例如，您在下面提到的建议似乎基于攻击者需要数年时间才能破坏的威胁模型一个单独的密钥。 使用 FS 密码套件，该威胁模型不应该与确定身份密钥的长度那么相关，因为给定的身份密钥早已不再使用。

RSA 3072 似乎是推荐（如 ENISA 和 NIST）在未来十年内使用的密钥的强大安全边际的最佳选择。

我在@AliceWonderMiscreations的论点中欣赏的一点是，我们生成的 2048 位密钥并不是单独打算在十年内使用，而是在几个月内使用，当它们用于验证 Diffie-Hellman 协商。 因此，在大多数情况下，这些建议可能会考虑不同的安全上下文。 可以想象，我们应该更担心大多数威胁模型中的 DH 模数，因为它是直接影响长期安全级别的限制参数。

我将尝试获取一些有关 FS 密码套件的使用频率以及 2048 与 3072 位密钥对服务器性能的影响的实际数据。

作为更新，我从几个不同的来源听到粗略估计，“大约 10%”、“不到 10%”和“大约 1%”的 HTTPS 连接现在使用非 FS 密码套件。 这是一个很难定义的目标，因为它取决于它是从浏览器的角度，从服务器的角度，在特定的国家，在特定的网站，针对特定类型的网站等等，以及那些类型的差异似乎解释了 1%-10% 的差异。

就个人而言，我更关心的是我们将旧的私钥保存在磁盘上（我提出了一个单独的问题，https://github.com/certbot/certbot/issues/4635）。 我认为这应该是一个更高的优先级，因为我认为攻击者为了读取旧流量而破坏服务器的可能性通常比攻击者为了这样做而破坏 2048 位 RSA 的可能性更大。

我建议如下：

• 我知道@dkg通常在 TLS 中的 DH 密钥交换的安全性方面做了很多工作。 您是否可以制作或找到一些工具来帮助扫描站点以估计客户端连接到每个站点时可能发生的 DH 交换的强度¹？ （我知道在您关心的某些领域中，我们无法从客户端真正看出交易所的安全性，但我只是在考虑尝试在一定程度上绘制出 DH 交易所的实力我们可以看到并确定它。）我们也知道很多对这类话题感兴趣的学术研究人员......

• 我仍然会尝试修复https://github.com/certbot/certbot/issues/4635 ，以便旧的、不再使用的私钥不会出现在 Web 服务器上。

• 也许我们可以考虑采取持续措施来鼓励用户升级他们的网络浏览器，以增加在 TLS 中使用的 DH 数量。

考虑到这一点，我将重申，我们默认生成的 2048 位密钥通常不用于直接保护会话密钥的机密性，而是用于验证 DH 密钥交换，其中攻击必须是在线的, 在证书的 90 天有效期内进行交互式、主动攻击。 否则，攻击者将不得不选择其他攻击途径。 我很难看到任何密钥长度建议的来源都认为 2048 位密钥不适合在 90 天的窗口期间进行身份验证。 它们与 1%-10% 连接的长期保密性更直接相关，但也许我们可以付出更多努力来降低这个百分比。

¹ 例如，关于算法以及关于公共参数大小和重用

我正在对有关 RSA 密钥的相关建议进行更多研究，但我计划尽快关闭此问题，除非有人在我最近的回复中对我的三个建议有任何回应。

在 #3349 完成后关闭它怎么样？

在 #3349 完成后关闭它怎么样？

我想说#6492 更相关，我们应该在 #6492 完成后关闭它（和 #4635）。

伙计们，4096 位加密不是免费的。 在低功耗 CPU 中速度非常慢。 即使是现代手机在使用时也会受到影响。 你确定从不可破解的加密货币到更不可破解的加密货币值得毁掉每个人的性能和电池寿命吗？

4096 位密钥长度在物联网中是一个大问题，因为这些设备的 CPU 能力通常非常有限。

在我们的一台较旧的嵌入式设备上，私有 RSA 坦克的速度从 3.6 到 0.6，从 2048 到 4096。

如前所述，物联网和其他没有硬件加速的设备可以使用 ECDSA (#6492)。

如前所述，物联网和其他没有硬件加速的设备可以使用 ECDSA (#6492)。

许多设备中是否有 RSA 的硬件加速，还是通常仍然通过软件处理？

某些 MCU 上提供硬件加速，但不是大多数（它更昂贵）。 此外，它通常限制为 3072，因为它是推荐值 (https://www.keylength.com/)
请注意，RSA 验证非常快。 只有生成和签名很慢。

OPENSSL_TLS_SECURITY_LEVEL=3至少需要 3072 位。

为什么这个问题仍然悬而未决？ 很明显，请求它的用户似乎误解了 TLS 的相关性，尤其是在 2020 年。

TL;博士

• RSA 证书仅用于证明服务器的身份是可信的，并且每 90 天更换一次。 在这段时间内，它不会因为 2048 位的密钥长度而受到损害，只是为了冒充您。
• 这是假设由于您非常关心安全性，因此您只允许提供 FS（DHE/ECHDE）的密码套件，而 DHE 也不是您真正关心的问题，因为对于网站而言，没有现代网络浏览器支持 DHE不再支持密钥交换（Safari 和 Chrome 在 2016 年左右放弃了支持）。
• 1024 位 RSA 与 2048 位 RSA 的攻击难度要高约 40 亿倍。 768 位 RSA 在 2010 年被打破（并行计算需要 2 年时间，相当于单机 2000 年），到 2020 年我们只达到了 829 位，512 位与 1024 位相比约为 10 亿难度倍数，而2048 位与 3072 位的难度仅高出约 65k 倍……
• 您的证书身份是在针对CA 证书的信任链中验证的，CA 证书的有效期更长，但仍然是 2048 位 RSA，您无法控制。 攻击者的目标是，如果他们想冒充您，那么当证书不用于其他任何用途时，将您的密钥长度增加超过该长度并不会提供任何额外的好处。

对于大多数部署，您应该只确保 PFS 密码套件，您的 RSA 证书在 2048 位之外没有任何好处，您只是减少了服务器可以同时支持的握手数量，因为额外的开销。 需要考虑建议的背景，而不是盲目地鹦鹉学舌。

仅将 DHE / ECDHE 用于密钥交换，使用 Web 服务器您会发现，自 2015 年以来，浏览器也逐渐取消了对 DHE的支持。 Safari 这样做是为了响应 2015 年的 Logjam，Chrome 在 2016 年（ Chrome 53（2016 年 8 月） ）放弃了 DHE 支持，因为仍有多少服务器与 1024 位 DH 组协商，而 Firefox 终于在今年加入了（ Firefox 78（ 2020 年 6 月） ）。 所以基本上对于网络，你只是在处理 ECDHE，除非你真的知道由于某种原因不能支持它的客户端，网络浏览器已经支持 ECC 很长时间了。

您现在还有什么可能担心的问题？ 您的证书将在 3 个月内更新/更换，RSA 证书的唯一安全问题是身份，一些攻击者可以冒充您，但要做到这一点，攻击者需要在该 <90 天的窗口内成功。

2020 年，迄今为止的记录打破了 829 位 RSA （距离我们意识到 768 位可破解已有 10 年），之前 795 位 RSA 的记录引用了更好的算法和硬件可以在大约一半的时间内实现其结果计算时间。 只需看看 900-2000 年的计算年数，这些成就就相当于它们的并行计算能力（768 位减少到 2 年）。

512 位 RSA 在安全性方面大约是 50 位对称密钥强度。 1024 位 RSA 称为 80 位，2048 位 RSA 称为 112 位，而本期中提到的 3072 位是 128 位。 是的，太棒了，所以 2010 年的 768 位 RSA（对称安全性介于 50-80 位之间）可能会在 2 年的跨度和大量资金中被打破，十年后我们已经设法做了一些对称的等价位更多。 对于任何这听起来像是胡言乱语的人来说，对称密钥强度中的每一位额外的位都会使计算工作量增加一倍，如果你要暴力破解所有可能性（平均而言，你会在所有处理过程中取得成功） .

现在比较 512 位 RSA 和 1024 位，对称安全性大约有 30 位差异，2^30 大约是 10 亿，即 50 位（1,125,899,906,842,624 个潜在密钥）乘以 10 亿（1,125,899,906,842,624,000,000,000），或者简单地说, 10 亿倍的努力/时间来打破。 使用 RSA 1024 位与 2048 位，您有 32 位的差异，2^32 略高于 40 亿。 所以我们有（4,503,599,627,370,496,000,000,000,000,000,000）。 现在，提升到 3072 位是更适度的 16 位额外安全性，2^16 == 65,536...是的，这将使它更“安全”，与我们的 40 亿乘数不完全相同，但是我们已经有了 2048 位 RSA 的难度显着增加。

现在让它沉浸并思考。 2010 年的 768 位 RSA 需要 2 年的并行处理时间，相当于单台机器 2000 年的时间，十年后，我们可以在所有这些进步上做得更好。 距离 1024 位 RSA 仍有很长的路要走，除非有人浪费大量金钱和时间想破坏你的 RSA 证书，这不像共享 DH 组，回报的价值要小得多，除非你拥有一些非常有价值的数据，无法通过身体折磨/勒索等更便宜的方式获得。

即使有人有这么多资源可以浪费在破解您的 RSA 证书上，也不是 1024 位，2048 位的难度是 40 亿倍，如果没有重大突破，这将不会发生，可能是密钥长度不足的弱点这不是一个问题（只需查看 TLS 中解决此类问题的所有其他漏洞）。 如果您超出了 3072 位 RSA 并且用于加密而恰好使用 128 位密钥，那么您的 RSA 证书就无关紧要了，AES 的 128 位加密密钥可能会被攻击而不是 afaik。

尽管如此，如前所述，我们只是在谈论 RSA 仅与身份相关，如果您仅使用 PFS 密码套件，无论您的资源是什么，有更好的方法来破坏您的服务器或用户，而不是破坏 2048 的成本- 不到 90 天的 RSA 证书...

OPENSSL_TLS_SECURITY_LEVEL=3至少需要 3072 位。

这有相关性为什么？ 那里有一个级别 5，要求最小 RSA 密钥长度为 15360 位，为什么用该逻辑停在 3072 位？

如链接文档所述，除非另有配置，否则默认值为1 。 你知道有什么主流软件编译 OpenSSL 3 级吗？ 大多数情况下，使用 OpenSSL 时，它会链接到系统副本，因为您希望接收安全更新而不依赖于每个应用程序更新自己的捆绑副本（假设软件首先定期维护/更新，在这种情况下并不总是发生）。

扫描站点以估计客户端连接到每个站点时可能发生的 DH 交换的强度

@schoen Chrome 在 2016 年放弃了对 DHE 的支持，他们注意到 95% 的 DHE 连接使用 1024 位 DH 参数。 现在这并不重要，因为现代浏览器不再支持 DHE 密码套件。

对于像邮件这样的其他服务器，它可能仍然有用（尽管 ECDHE 支持已经有一段时间了，一些 Linux 发行版如 RHEL 直到 2014 年左右的 6.5 才支持）。 DHE 应使用 RFC 7919 中的官方 FFDHE 组，该组至少有 2048 位。 具有 1024 位限制的旧客户端都无关紧要，对于系统管理员可以解决问题的利基情况，但此时可能会遇到许多安全问题，包括潜在的链由于系统上的根证书过期而导致的信任问题。

也许我们可以考虑采取持续措施来鼓励用户升级他们的网络浏览器，以增加在 TLS 中使用的 DH 数量。

当您提出此建议时，Safari 和 Chrome 不再提供 DHE afaik。 这将产生相反的结果，减少 DHE，假设用户甚至能够升级运行过时软件的设备上的浏览器/客户端。 一些旧的操作系统或软件被锁定到旧的 TLS 实现（如 macOS / iOS 安全传输），这会影响 TLS 版本支持、支持的密码套件（macOS 直到 2015 年末发布 IIRC 才缺少 AES-GCM）。

对于那些认为 2048 位 RSA 不足以进行 90 天身份保护的人，忽略 OCSP 和 CT 日志等其他保护措施，您知道信任链吗？ 您的证书已根据 LetsEncrypt 根证书和中间证书进行验证，如果有人想攻击证书，则破坏这些证书比颁发给特定站点的证书更有价值。

如果证书仅用于真实性而不被泄露以解密任何记录的流量，那么您可以随心所欲地增加您的网站密钥长度，但是您从这种理论攻击中获得了什么保护，因为您比以前更安全信任链中的证书被泄露？ （使用 2048 位 RSA，〜包括 LE 根〜（编辑：我的错， LE RSA 根是 4096 位），有效期更长，中间为 5 年，LE 根到 2035 年）

为什么这个问题仍然悬而未决？ 很明显，请求它的用户似乎误解了 TLS 的相关性，尤其是在 2020 年。

TL;博士

* RSA certs only matter for **proving the identity of the server can be trusted**, and are being **replaced every 90 days**. It won't be compromised due to key length of 2048-bit within that time just to impersonate you.

似乎您不太了解 X.509（而不是 TLS :rofl:)... :rofl:
证书不是问题，但关键是。 而在 X.509 世界中，密钥是不可能撤销的……所以 90 天翻转在这里并不总是相关的，对于不使用 ECDHE/DHE 而是使用普通旧 RSA 身份验证的服务器来说，这是一个麻烦。 这在 2020 年也是如此……

你也算错了 RSA-2048 的强度。 您不仅要计算破解给定密钥的最佳当前方法的时间，还要计算将来您的密钥不再有意义的未来时间。 如果不是 ECDHE/DHE（我重复一遍，不是很罕见），它不是 90 天，而是 10-30 年。 这不仅是要考虑的时间，还要考虑成本、技术发展和加密弱点/技巧发现。 它在您的解释案例中特别明显。
RSA-256 于 2019 年 9 月在约 1000 美元的标准笔记本电脑上破解了约 60 秒。 但 RSA-512 在 2015 年大约 4 小时和大约 75 美元就破解了。
https://www.doyler.net/security-not-included/cracking-256-bit-rsa-keys
https://eprint.iacr.org/2015/1000.pdf
两者之间肯定没有[在此处插入一个很大的数字]倍数差异，但在恒定成本下或多或少是 1.8。
它在用于分解 RSA 密钥的cado-nfs基准测试中也很明显。 RSA-120 是 1.9h，RSA-130 是 7.5h（而不是预期的 81d），RSA-140 是 23h（而不是 227y），RSA-155 是 5.3d（而不是 7452 千年）。

这就是为什么像 ANSSI 或 NIST 这样的实体的建议不仅基于当前最先进的计算机能力或密码学知识，而且基于预期在密钥使用/意义完整的时间范围内发生的未来改进

对于不使用 ECDHE/DHE 而是使用普通旧 RSA 身份验证的服务器来说，这是一个麻烦。 2020 年也是如此

因此，您在这里提高安全性的建议是鼓励使用更大的密钥大小，而不是鼓励仅使用 PFS 密码套件？ 为什么？

你也算错了 RSA-2048 的强度
您不仅要计算破解给定密钥的最佳当前方法的时间，还要计算将来您的密钥不再有意义的未来时间

请进一步详述。 在过去的十年中，您是否知道这是错误的。 没有已知的 1024 位 RSA 被分解/破坏的情况，更不用说 2048 位，它在查看对称密钥强度时具有 2^32 位更多的熵。

1. 2048 位 RSA 比 1024 位 RSA 强约 40 亿倍。
2. 3072 位仅强约 65k 倍（比较 NIST 官方定义的 112 位和 128 位对称安全性）。
3. 如果我们假设 1024 位（80 位对称密钥强度）可以在 1 年的计算能力范围内受到影响。 对于 2048 位，这是 40 亿年。
4. 您声称一些未知的技术进步可以大大减少计算时间，但不会威胁到 3072 位 RSA？

我们可以比较 1024 位在 1 秒内可破解，那么 2048 位仍然相当于 136 年（ (1/31536000) * 2^32 ）。 这样的成就距离实现还有很长的路要走，如果您想坚持认为这是一个有效的担忧，您是否知道甚至 512 位也被考虑在 1 秒内？ 512 位 RSA 于 1999 年首次分解超过 6 个月，自 2015 年以来出现了一个Github 项目 (FaaS) ，它使您能够以不到 100 美元的价格轻松利用 AWS，并在几个小时内分解 512 位 RSA。

考虑到这一点，1024 位 RSA 的难度大约是 2^28（~250k）到 2^30（10 亿）倍（抱歉，我没有确切的数字，但似乎差不多），而目前的学者离那还很远，我不确定你认为 1024 位 RSA 的计算速度有多快，在 2048 位 RSA 甚至担心以这种方式被破坏之前它需要如此.

这里常用的方法是GNFS（通用数字字段筛选器），密钥大小越大，所需资源就越不可行。 还有一张漂亮的 RSA 分解历史图表，以及一个相关的答案，基于此，将 2048 位 RSA 固定在 2048 年分解，到 2015-2020 年分解为 1024 位，这在学术上尚未实现。

考虑到上述情况，我希望您支持 3072 位 RSA 如何提供更多额外的安全优势。 如果 2048 位 RSA 以任何其他方式受到攻击或在技术上以这样的速度发展，那么我看不出 3072 位 RSA 将如何提供更多额外保护？

如果不是 ECDHE/DHE（我重复一遍，不是很罕见）

我喜欢你声称它“不太罕见”的方式，现在你遇到握手使用 RSA 密钥交换而不是 DHE 或 ECDHE 的情况有多普遍？ 你有一个例子吗？

不是 90d 而是 10-30y

我相信我很清楚地说明了证书的 90 天续订期，因为它的目的只是提供身份验证，而不是密钥交换。

这不仅是要考虑的时间，还要考虑成本、技术发展和加密弱点/技巧发现。 它在您的解释案例中特别明显。

是的，成本。 资源 我已将您链接到引用 1024 位 RSA，需要 TB 的 RAM 才能在其上执行 GNFS，线性缩减步骤是最昂贵/最难处理的部分。 这就是指数难度的事情，便宜/容易的事情会很快增加难度。

RSA-256 于 2019 年 9 月在约 1000 美元的标准笔记本电脑上破解了约 60 秒。 但 RSA-512 在 2015 年大约 4 小时和大约 75 美元就破解了。

我已经链接到可以在 AWS 上执行 512 位分解的 Github 项目。 我不知道 256 位 RSA 的对称熵位的确切数量，可能在 30 位左右？ （因此 512 位 RSA 之间的差异大约为 1,048,576 倍）。 您链接到的 512 位论文提到了 432 个 CPU（12 个实例，每个实例有 36 个 vCPU + 60GiB RAM），总共 2770 个 CPU 小时，1.5-2GB 内存或存储用于矩阵（我不太熟悉这个计算，如果您可以随意插话）。

我的数学在这里可能很糟糕，但让我们尝试根据该信息比较两个系统的计算能力，2770 小时到分钟将是2770 * 60 = 166200 ，我们可以将 256 位 RSA 的 1 分钟作为log2(166200) = 17.34进行比较

1991 年，330 位 RSA 在几天内被分解，后来的单个 Intel Core2Duo CPU 可以在一个多小时内处理它。 256 位 RSA 会比那时少，让我们乐观地假设 60 分钟，然后说它在大约 30 年内下降到大约 1 分钟，大幅减少了 60 倍。 这相当于说 2^6 (64)... 6 位。 如前所述，仅考虑时间方面，而不是诸如增加 RAM 需求之类的资源，这距离成为有效威胁还有很长的路要走。 在接下来的 30 年中再减少 6 位，并且您已经管理了 256 位 RSA 的 1 秒因式分解，恭喜，在合理的时间范围内实现 2048 位 RSA 的路很长。

即使是 512 位 RSA 从 6 个月缩短到 4 小时的 15 年也是24hr * (6month * 30day) = 4320hr / 4hr = log2(1080hr) = 10 ~2^10。 这肯定比减少更好，大约好 1k 倍，但相比之下仍然不是一个惊人的速度。 我认为，随着学术界能够考虑更大的 RSA 密钥大小，进展如何放缓进一步支持了这一点。

它在用于分解 RSA 密钥的 cado-nfs 基准测试中也很明显。 RSA-120 是 1.9h，RSA-130 是 7.5h（而不是预期的 81d），RSA-140 是 23h（而不是 227y），RSA-155 是 5.3d（而不是 7452 千年）。

这些预期的计算时间来自哪里？ RSA-155（又名 512 位 RSA）在 1999 年的 6 个月内被考虑在内，RSA-120（397 位 RSA）和 RSA-130（430 位 RSA）同样可能只有大约 1-2 位对称位不同? 因此预计增加约 4 倍...？

这就是为什么像 ANSSI 或 NIST 这样的实体的建议不仅基于当前最先进的计算机能力或密码学知识，而且基于预期在密钥使用/意义完整的时间范围内发生的未来改进

您没有提供任何实质性的信息表明 2048 位 RSA 几乎很弱，即使在历史背景下已经取得了显着的改进，这看起来与指数增长无关。 您似乎采取了某种线性的观点？ 我希望你知道为什么 128 位 AES 被认为是安全的（显然有一天使用 Grover 算法的量子计算机可能会很弱）并且据说 256 位 AES 需要我们太阳系的全部能量用蛮力破解。

此外，考虑到哪些数据是敏感数据，您试图保护它，而不考虑最佳实践，例如仅使用支持 PFS 的密码套件，这些数据也被认为有问题，可能在几十年后被解密（相当多的几十年后，敏感数据不像现在那么重要）。

TL;博士

这几乎可以归结为这一点。 打破 2048 位，即使从现在起几十年，仍然会非常昂贵，但让我们乐观一点，说 100 万美元和 10 年（如果你愿意，也可以是 1 年）。

• 这个攻击者现在是否对你特别感兴趣，因为他们将有能力为 N 个用户记录你的服务器流量（其中 N 与存储要求无关，因为无论如何你都在不安全地使用相同的密钥进行所有加密） .
• 此流量将被记录 X 年，您的证书每 90 天都会更改一次，需要对每个流量进行单独的攻击（时间和 $$$$）？ 或者攻击者提前知道何时记录他们感兴趣的特定数据，即使他们相信他们可以破解加密还需要几十年的时间？
• 与直接入侵您的服务器或用户客户端并破坏该系统相比，这在某种程度上是一种更好的策略，而且成本更低（我的意思是，他们已经将自己置于中间人攻击中以捕获流量，并且无论如何都要以足够的资金访问您的秘密，对吧？ )，他们会没有可用的资源来选择更实际的攻击吗？
• 直接威胁或勒索某人以访问 RSA 私钥不是更便宜、更容易吗？ 那么密钥长度就无关紧要了，如果你很聪明并且只使用 PFS 密码套件，那么这个策略就无关紧要了。

呜呜基本...

鼓励 PFS 密码套件 (DHE / ECDHE) 对创可贴不良安全实践进行不小的改进

因此，您在这里提高安全性的建议是鼓励使用更大的密钥大小，而不是鼓励仅使用 PFS 密码套件？ 为什么？

因为 LE 掌握了默认密钥大小，而不是 httpd 配置。 并且 LE 过去已经采取了行动（在 HTTP-01 上禁用 https，从 TLS-SNI-01 中移除……）而不是强制执行 httpd 配置。

请进一步详述。

当然。 并简单地查看 cado-nfs 的基准。 破解时间不是预期的理论时间。
由于两个偏差，在实践中没有观察到理论难度差距。 我们只能比较给定现有技术和当前时间的破解时间，并期望理论上的差距（实际上，情况并非如此，请参阅 cado-nfs），但没有什么能确保 X+1 位为 2如果我们将当前的知识和计算能力与 1 个月后我们将拥有的能力进行比较，则比 X 困难倍。
另请参阅我给出的 2 个示例。 考虑到相同的功率和成本，在 2015 年和 2019 年之间，256 和 512 位之间只有 2 倍的差距，理论上有 10⁷7 倍的差距。
而且我们无法确保明天不会出现 3072 RSA 破解技巧，而 4096 位将保持更安全。

我已经链接到可以在 AWS 上执行 512 位分解的 Github 项目。 我不知道 256 位 RSA 的对称熵位的确切数量，可能在 30 位左右？ （因此 512 位 RSA 之间的差异大约为 1,048,576 倍）。 您链接到的 512 位论文提到了 432 个 CPU（12 个实例，每个实例有 36 个 vCPU + 60GiB RAM），总共 2770 个 CPU 小时，1.5-2GB 内存或存储用于矩阵（我不太熟悉这个计算，如果您可以随意插话）。

是的，这似乎是一个巨大的数字并且不切实际……在第一个 512 位中断（1999 年）的时候，它被认为是不切实际的，因为它要求没有人拥有的超级计算机。 但事实上，2015 年此类基础设施的相应 AWS 账单是…… 4 小时 100 美元，几年后IS实用，大大快于 1999 年预期的数十亿美元的差距。
https://arstechnica.com/information-technology/2015/10/break-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/

考虑到相同的功率和成本，在 2015 年和 2019 年之间，256 和 512 位之间只有 2 倍的差距，理论上有 10⁷7 倍的差距。

什么……不。 我在我的帖子中已经非常清楚地告诉你，256 位和 512 位之间的区别不是 2^256（你的基​​数 10、10^77），而是更像 2^20 或更少（在我对你引用的两个分解示例进行了比较，大约是 2^17）。

我也不确定您是如何声称“2 倍差距”的？ 相同的功率和成本？ 256 位 RSA 大约需要 1 分钟，而 512 位 RSA 相当于 166,200 分钟（我之前的帖子中引用了数学，如果我犯了错误，请随时纠正我）。

而且我们无法确保明天不会出现 3072 RSA 破解技巧，而 4096 位将保持更安全。

从字面上看，您对 2048 位 RSA 没问题，3072 位 RSA 在安全性方面有“边际”改进，我已经解释过了，您似乎跳过或误解了它？ 2048 位 RSA 在更短的时间内变得不安全的唯一方法是您的 3072 位 RSA 将受到发展速度的威胁。

如果您想更安全，请不要使用 RSA 进行密钥交换。 我已要求您引用一个需要 RSA 密钥交换的网站（无论出于何种原因，不支持/协商 (EC)DHE），您为什么无法回答这个问题，您声称这是一种常见的情况，有理由提高默认 RSA 密钥长度？ 请支持该声明。 您可能会发现提供 RSA 作为密钥交换的服务器，它们可能会启用服务器密码套件选择，但是任何支持 PFS 密码套件的客户端都不会对其进行协商。

但事实上，2015 年此类基础设施的相应 AWS 账单是…… 4 小时 100 美元，几年后 IS 实用，大大快于 1999 年预期的数十亿美元的差距。

硬件的成本远高于 100 美元，不是荒谬的数额，但是是的，可以轻松租用/访问这样的计算资源使其更容易获得。 请注意所使用的硬件，它不是便宜/小型 EC2 实例，在租用计算资源时这些机器相当大，我们已经考虑了 768 位 RSA 十多年了，但你看不到 FaaS能够便宜地处理吗？ 2048 位 RSA 任重道远。

您是否有任何人声称 512 位需要超过 10 亿才能进行计算？ 可以肯定的是，1999 年仅用 6 个月计算的硬件资源距离数十亿美元的成本还有很长的路要走。 这个价格是从哪里来的？ 来自最近关于更高安全性的声明？ 这是由于难度呈指数增长，这不仅需要更多的计算时间，还需要其他资源，如 RAM。 那些 512 位 RSA 分解 AWS 实例有 60GB 的 RAM，每个（总共 720GB）......

快速浏览一些处理见解：

2020 年考虑的 RSA-250（829 位 RSA）是在 3 个月内用数万台计算机和使用你喜欢提出的 CADO-NFS 实现的，似乎他们已经实现了大约与 2015 年实现的 512 位 RSA 的 AWS 分解（大约 2700 CPU 小时，将 AFAIK 标准化为引用的 Intel Xeon Gold 6130 2.1GHz）相同的计算时间（编辑：我的错误，几年，而不是小时）。 2019 年 12 月分解的 RSA-240（795 位 RSA）很有趣，因为它是由同一团队和在 2010/2016 年分解 768 位 RSA（也使用 CADO-NFS）的同一硬件上的。 他们注意到 CADO-NFS 软件中的算法改进，因为这可以实现约 3 倍的性能提升。

这是关于 2010 年 768 位 RSA 分解的论文，请查看 RAM 要求：

第一阶段被分成八个独立的作业，在这些集群上并行运行，八个序列中的每一个每 214 步检查一次。 运行第一（或第三）阶段序列需要 180 GB RAM ，单个 64 位宽¯b 需要 1.5 GB，单个 mi 矩阵 8 KB，其中每个第一阶段序列平均保留 565 000 个。 第三阶段评估期间的每个部分总和需要 12 GB 。

大多数情况下，可用的 896 GB RAM 就足够了，但在计算的中心部分需要更多内存（最多约 1 TB）

让我们将其与512 位 RSA 分解（2009 年，而不是 2015 年的 AWS 分解）进行对比：

到 2009 年，Benjamin Moody 仅使用公共软件 (GGNFS) 和他的台式计算机（具有 1,900 MHz cpu 的双核 Athlon64）就可以在 73 天内分解一个 RSA-512 位密钥。 筛分过程只需要不到 5 GB 的磁盘存储空间和大约 2.5 GB 的 RAM。

随着密钥长度的增加，这应该会给出一个粗略的 RAM 需求缩放比例。 我敢肯定，处理过程中可能还有其他瓶颈需要注意，尤其是在以分布式方式进行处理时。 随意进一步研究并确定攻击 2048 位 RSA 需要多少 RAM。

你到底是谁在试图保护自己免受那些专门针对你或你的用户流量的攻击，以记录它并在几十年后执行攻击？

不是一些脚本小子在等待 100 美元的 AWS 解决方案，到那时他们会转向更好的事情，并且破坏您的网络以记录流量会花费更多，否则这是一些没有特定目标的恶意软件，恭喜您记录的数据分段每个 RSA 密钥的 90 天流量现在在许多其他人的海洋中，可能是数千，数百万，即使可能，100 美元的 AWS 也不会很便宜来攻击所有这些，特别是当数据具有未知价值时，会有一个很多垃圾可以扔掉钱。

不，如果有人想要你的秘密，还有更实惠的方法。

出于某种原因，您认为 1024 位到 2048 位 RSA 的安全性提高 40 亿倍是不够的，但是从 2048 位到 3072 位 RSA 的安全性提高 65k 倍就足够了。 您的论点是 2048 位在计算上是安全的安全理论是无效的，但是对于 3072 位 RSA 的相同逻辑如何不适用并且更安全？ 玻璃门是否更安全，因为我添加了更大更安全的锁？

TL;博士

请查看以前的 TL;DR，但我会​​重新迭代..

• 有人想使用弱2048 位 RSA 密钥记录您的加密流量。
• 他们有能力执行这种中间人攻击，因此他们有技能或金钱，这可能是有针对性的攻击。
• 您的数据必须在未来保留其现在希望获得的价值，即使根据您的估计它可能仅在 20 多年后才能解密。
• 攻击需要对获得秘密值的执行成本是合理的，必须知道要捕获哪个 90 天窗口，否则必须多次计算攻击以希望获得所述秘密。
• 这种攻击在某种程度上比任何其他方法更有效地以更快/更便宜的方式获取所述数据？

谁在他们的头脑中会这样做？ 这只会在没有其他获取该信息的方法可行的高价值目标上可行。 所述目标以某种方式拥有如此宝贵的秘密，但不费心向专业人士付费或考虑保护它们的最佳实践（他们显然无法通过复制/粘贴 Mozilla 的密码套件建议来设置服务器）。

这不是很有说服力。 这不是 LetsEncrypt，您假设拥有宝贵机密的用户使用 Certbot 以及其服务器支持的仅 RSA 密钥交换密码套件（没有默认配置这样做），并且 2048 位 RSA 比它弱得多？ 不管这个用户是谁，他们在其他地方的安全实践可能已经弱到足以直接危害他们，为什么要等待 20 到 30 年才能解密数据，而您现在可以执行主动攻击并获得所有多汁的数据？

正确的解决方案是正确设置密码套件，如果您在该领域没有经验并希望依靠它来为您处理， Certbot项目正是这样做的。 但出于某种原因，这不适用于本次讨论？

我已要求您引用一个需要 RSA 密钥交换的网站（无论出于何种原因，不支持/协商 (EC)DHE）

https://cryptcheck.fr/https/bankofamerica.com （是的，你没看错）
https://cryptcheck.fr/https/caf.fr （法国国家行政部门，相当于美国的补充保障收入）
https://cryptcheck.fr/https/xn--trkiye-3ya.gov.tr
https://cryptcheck.fr/https/pfisng.dsna-dti.aviation-civile.gouv.fr
https://cryptcheck.fr/https/reader.xsnews.nl
https://cryptcheck.fr/https/protecpo.inrs.fr
https://cryptcheck.fr/https/tiscali.it

我在我的 CryptCheck v2 上计算了 68 个非 PFS 域，超过 7221 次握手分析（~0.9%）和 2091 个超过 349961 次握手分析（~0.6%）。

https://www.bankofamerica.com/

协议：TLS 1.2
密钥交换：ECDHE_RSA
密钥交换组：P-256
密码：AES_128_GCM
CA：委托

https://cryptcheck.fr/https/bankofamerica.com应该为不提供 ECDHE 密钥交换的同一域识别其他服务器 IP？

https://www.caf.fr/

协议：TLS 1.2
密钥交换：RSA
密码：AES_128_CBC 和 HMAC-SHA1
加利福尼亚州：Certinga

我不知道这个网站是关于什么的，也不知道它必须利用什么敏感秘密？

https://www.turkiye.gov.tr/

协议：TLS 1.2
密钥交换：RSA
密码：AES_128_CBC 和 HMAC-SHA1
CA：全球信号

我是从您看起来怪异的域名重定向到这个的，我无法想象有人会直接访问它并认为它是合法/值得信赖的名称。

这就像许多其他人一样，显然是一个政府网站。 它们通常落后并且需要被广大受众访问，尽管 RSA 不应该是默认的密钥交换，但同样，这里发生了哪些通信是您想要保护自己免受攻击的？ 显然，政府自己似乎并不太担心。

https://pfisng.dsna-dti.aviation-civile.gouv.fr/jts/auth/authrequired

协议：TLS 1.2
密钥交换：RSA
密码：AES_128_GCM
加利福尼亚州：Certinga

同样，除了登录的政府服务之外，不知道这是什么。 除了登录详细信息之外，是否还有任何敏感信息？ 从现在起 20 到 30 年后，对于敏感信息的访问有哪些担忧？ 我在其他地方使用相同的用户名和密码，并且在 20 到 30 年后仍然继续这样做？

如果需要登录详细信息（以及帐户数据的价值），网络钓鱼诈骗不会同样有效。 与攻击 RSA 证书相比，这能否在更短的时间内或更少的预算内实现？

https://reader.xsnews.nl/

尝试加载/解析 URL 花了超过一分钟，我无法访问该网站。

https://protecpo.inrs.fr/ProtecPo/jsp/Accueil.jsp

协议：TLS 1.2
密钥交换：RSA
密码：AES_128_GCM
CA: GEANT

这似乎是一些可用于帮助做出购买决定的软件的网站。 这里有哪些敏感信息存在风险？

https://www.tiscali.it/

协议：TLS 1.2
密钥交换：RSA
密码：AES_256_CBC 和 HMAC-SHA1
CA：解冻

新闻网站？ 同样，与本网站交互时需要关注哪些敏感信息？

概括

这些结果中的任何一个都没有表明需要保护敏感通信超出估计的 20-30 年 2048 位 RSA 受到损害。 这些网站仍然需要有效的中间人攻击来捕获客户端和服务器之间的流量，这对它们中的任何一个来说都不是一个有效的问题？

这些都不使用 LetsEncrypt 颁发的证书。 仅当您确定这些网站专门使用 Certbot 作为这些 CA 的 ACME 客户端（假设它们具有第三方 ACME 支持）时，对 Certbot 进行更改才是有益的。

感谢您实际上指出了一些 RSA 是协商密钥交换的网站（除了美国银行，这似乎是不正确的，并且仅被验证为面向公众网站的密码套件，而不是任何实际的敏感交换）。

我在我的 CryptCheck v2 上计算了 68 个非 PFS 域，超过 7221 次握手分析（~0.9%）和 2091 个超过 349961 次握手分析（~0.6%）。

好的，那么在您使用 CryptCheck 扫描的 7,221 和 349,961 个网站中，您的“不稀有”不到 1%？ 现在考虑使用 3072 位 RSA 来保护这些通信所提供的受众和实际可衡量的价值，它实际上是否可以保护任何有价值的东西，并且对于更便宜的替代方案来损害安全性是否更安全？ （例如，2048 位比任何其他替代目标攻击更弱/更便宜，其中 3072 位提高了攻击的下限）

Alexa 排名前 100 万的站点中有多少正在协商 RSA 密钥交换？ 有多少人使用 LetsEncrypt 作为 CA？

我计算了 512 位和 256 位 RSA 的对称位（基于 NIST 的方程），我们得到 40 位（256 位 RSA）和 57 位（512 位 RSA）。

有趣的是，这与前面提到的 17 位差异相匹配，将这两种计算方式与最近的进步进行比较（我引用的 NIST 文档似乎是在 2020 年最后更新的）。

它还揭示了与 1024 位 RSA 的距离仅为 23 位等效对称密钥强度 8,388,608。 我们可以看到 768 位和 795 位 RSA 的当前进度或 829 位 RSA 的当前记录是：

768 == 69.74588053597235
795 == 70.91595938496408
829 == 72.35600867501326

• 自 2010 年以来的 768 位 RSA 记录和 2020 年的 829 位 RSA 记录，十年间的改进不到 3 位。 2000 与 2700 CPU 年（单核）。 795 位 RSA 在 2019 年 11 月降至 900 CPU 年。
• 57 位（512 位 RSA）到 72 位（829 位 RSA），计算时间约为 2700 小时~（编辑：小时与年，哎呀）在 2015 年至 2020 年之间。~15 位（32,768）改进~？ （相比之下，829 位 RSA 需要 3 个月和数万台机器）。 仅由于软件/算法的改进，768 位（2009 年 12 月）和 795 位（2019 年 11 月）RSA 因式分析的速度提高了约 3 倍。
• 2^6 (64) 估计自 1991 年以来 256 位 RSA 的改进。
• ~2^10 (1024) 与 16 年 (1999 - 2015) 6 个月与 4 小时 512 位的 1080 x 差异，不清楚比较的准确度，8,000 MIPS 年与英特尔 CPU 的 2770 年通常参考。 这里的主要差异可能是由于可以通过云计算廉价地租用硬件以缩短时间，同时利用 15 年来对软件的硬件改进和算法改进。

我刚刚意识到我之前在引用 829 位 RSA 分解并将其与 AWS 512 位 RSA 分解时间进行比较时犯了一个错误。 他们都引用了大约 2700 个计算单位时间，但我发现 829 位 RSA 是年，而 512 位 RSA 是小时。 这似乎相差大约 8,760 （ (8760hrs * 2700yrs) / 2700hrs ，其中 8,760 是一年中的小时数）乘以（2^13），我认为是 4 年（ (4hrs * 8760hrs) / 24hrs / 365days ），这将接近在 AWS 上花费一百万美元的计算时间？ （忽略您可能需要更多 RAM 的事实）

256 位 RSA 1 分钟计算时间与 829 位 RSA 2700 年计算时间 = log2(525600mins * 2700yrs) （一年中的分钟数）大约等于 2^30。 同样，类似于 512 位 RSA 计算难度，这与假设的 2^32 位强度差异非常接近。 我们也许可以更快地分解 RSA 密钥，但计算难度似乎大致保持不变？

不是最好的信息，但足以让我们大致了解进步和改进的速度。

• 几十年来，计算的难度大致准确且一致？
• 改进计算以更快地执行因式分解的速度已经很好地提高了，但不是很大？

1024 位在一段时间内仍然遥不可及，而根据上述历史进展，2048 位更是如此。 几乎没有证据表明 3072 位 RSA 加上 2^16（65k）到 2^22（400 万）位的额外难度将比 2^30（10 亿）到 2^ 带来更多的安全优势32（40 亿）个 2048 位具有超过 1024 位的 RSA。 （并不是说它不会增加显着的额外难度，而是基于假设 2048 位 RSA 本身在应该时不能充分支撑）

基于当前的 829 位 RSA 工作，2048 位 RSA 的位安全级别大约有 38 位差异。 如果我们采用在 3 个月内计算 829 位 RSA 的恒定计算能力（一年中有 4 个三个月的持续时间），我们得到 68,719,476,736 年（ 2^38 / 4 ），即使我们有进步将其降低到 1十亿倍的工作量（2^30），它仍然是大约 64 年，这就是数万台机器。

如果您仍然认为至少 3072 位是值得的，尽管我（可能很糟糕？）数学、成本效益分析和常识推理......那么我认为我没有其他任何东西可以说服你.

请记住，您是在倡导使用 Certbot 进行更改，而不是 LetsEncrypt 强制执行最低发行量。 Certbot 已经通过配置适当的密码套件来帮助用户，从而避免了整个问题，所以谁真的会在这里受益——而其他没有使用 RSA 作为密钥交换的人（使用 Certbot）正在增加更多的负载和带宽他们的服务器（即使对大多数人来说都是次要的）。

问题应该关闭。

https://www.keylength.com/

https://www.keylength.com/

4 年前，您已经在此线程中提供了该信息。 您似乎不了解该网站的建议的上下文以及它在此处的应用方式。

如果您对 3072 位 RSA 或更大的证书密钥长度感到更自在，明确选择您已经可以的，那么在关心实用安全性时没有正当理由采用 3072 位作为新的默认值. 2048 位 RSA 就足够了。

4 年前，您已经在此线程中提供了该信息。 您似乎不了解该网站的建议的上下文以及它在此处的应用方式。

你不明白更多。 例如，ANSSI 建议

作为远程服务和行政与用户之间电子交换发展的一部分，行政当局必须保证其负责实施这些服务的信息系统的安全。
一般安全参考特别适用于行政当局在相互关系以及与用户的关系中实施的信息系统（这些是远程服务，例如向行政部门支付罚款）。
间接地，通用安全参考适用于协助行政当局保护其实施的电子交换的所有服务提供商，以及提供产品的制造商。 的安全性。
一般而言，对于希望组织管理其信息系统和电子交换的安全性的任何其他组织，提供通用安全参考作为符合最新技术的良好实践指南。

因此在法国适用于任何目的和任何方式，并且完全不限于军事目的等明智的背景。

其中一个建议是“建议使用至少 3072 位的模块，即使使用不超过 2030 ”。 并且 3072 位不再是一个建议，但如果在 2030 年之后预期使用/影响，则它是强制性的。

即使是关于隐私和良好实践的法国实体 CNIL，也将 ANSSI 论文用于任何网站的标准推荐： https ://www.cnil.fr/fr/securite-securiser-les-sites-web

ANSSI 已在其站点上发布了实施 TLS 或保护网站的具体建议。

（并且也反对 Let's Encrypt，因为声明你必须you must authorize only incoming IP network flows on this machine on port 443 and block all the other ports.但是这个）

NIST 建议不受传递信息敏感性的约束，而是适用于所有情况的一般建议，您也必须管理密钥或证书。

这不是 LE 第一次使用默认配置来反对政府机构或其他机构的最新建议……

哦，BSI 今年审查了它的建议。 它指出比

重要提示：为 RSA、DH 和 DSS 使用 3000 位的密钥长度是合理的，以便为所有非对称机制实现同质的安全级别。 从 2023 年起，加密实施需要至少 3000 位的密钥长度，以符合本技术指南。

@aeris即使法国强制实施 3072 位 RSA，这在其他地方也不是法律。 请注意建议和建议也不等同于强制性要求。

如果他们还建议在密码套件中使用 RSA 密钥交换作为安全/隐私的最佳实践，我会感到惊讶。 如果您想正确处理安全和隐私，请仅采用 PFS 密码套件，您的 RSA 证书从那时起将不再相关，因为它仅在身份验证中起作用。

无论如何，我觉得我在这里重复自己，我对没完没了的来回不感兴趣。 如果您必须遵守某些安全机构/建议，请明确说明。 我已经相当详细地说明了 2048 位是安全的，并且在可预见的未来仍然如此，如果不是这样，3072 位 RSA 也不再可能是安全的。

由于您对这个主题相当热情，请尝试掌握我转达给您的内容，而不是背诵 NIST / ANSSI / BSI / 等，建议比需要的高一点符合他们的最大利益，类似于AES- 128 是作为 AES 的最低/最弱安全级别引入的，但它本身就相当安全。

你从 3072 位获得的只是一种“更安全”的错误感觉，因为 2048 位已经绰绰有余，如果不是，没有理由认为 3072 位会更安全，因为它额外的 16 位安全性跟不上这种进步。 做聪明的事，不要继续使用 RSA 作为密钥交换......如果你只依赖更大的 RSA 密钥长度作为你的安全感，而不是在其他地方应用安全实践，你就是在自欺欺人。

如果您想继续为合规而不是实际的安全利益而争论，我会留给您。 就个人而言，默认更改为不值得，而且对于大多数 Certbot 用户来说，由于存在缺陷并且在实际安全性方面没有实际收益，因此可能不受欢迎。

这不是 LE 第一次使用默认配置来反对政府机构或其他机构的最新建议……

可能是因为他们知道得更好，不管你怎么想。 即使之前向您提供了所有信息，您似乎对它根本不感兴趣或对此持开放态度。

虽然它可能不会进一步说服你，但这是成功攻击所需的 2^128 位对称强度：

目前世界能源消耗总量约为每年 500 EJ (5×10^20 J)（或本文所述）。

这将导致2040 年的总数为 2^138 - 这是一个为期十年的计算，它调动了整个星球的所有资源。

另一个有趣的见解：

综上所述：即使你把世界上所有的美元（包括不存在的美元，比如积累的债务）都用光了，在这个过程中炒了整个星球，你也只能勉强做 1/1000 的穷举键搜索。 128 位密钥。

顺便说一句，256 位对称加密密钥将超过我们太阳系内可用于破解的所有能量：

物理宇宙的法则意味着即使是这些大小适中的钥匙也永远不会被暴力破解。 这并不是说它们永远不会被打破。 可以在算法中发现缺陷

没有什么比“不能打破它”更强大的了，所以比较超过 100 位左右的强度无论如何都是没有意义的。 -来源

现在所有这些引用都集中在 3072 位 RSA 等 128 位密钥上，但 2048 位 RSA 的 110-112 位仍然相当可观。 然而，走XKCD 建议的路线要便宜得多 :)

看起来争论已经从安全转向合规。

看起来争论已经从安全转向合规。

或不。 这只是来自与安全生态系统相关的知名实体的最新建议，关于默认情况下使用什么来避免在你的脚下射击，正如我们至少十年以来在 TLS/X.509 世界中经常看到的那样。