Hormoz Asked: 2021-08-14 10:47:23 +0800 CST2021-08-14 10:47:23 +0800 CST 2021-08-14 10:47:23 +0800 CST 雷鸟密钥生成仍然安全吗？ 772 关于 Thunderbird 中涉及的 PGP 密钥生成的细节，我找不到太多信息。该软件相当陈旧，诸如“这可能需要几分钟”之类的东西，而它只需要不到一秒钟，有点让我挑眉。 虽然软件经常更新，但密钥生成算法对它来说是否仍然安全，因为如果密钥生成很弱且可预测，那么 PGP 的安全性并不重要。 thunderbird 1 个回答 Voted Best Answer user1686 2021-08-14T12:02:20+08:002021-08-14T12:02:20+08:00 Crypto.SE 或 Security.SE 将能够提供比我更好的来源答案（我不从事密码学工作），但是： 关于具体实现，如果您使用的是最新的具有内置 OpenPGP 支持的 Thunderbird（这实际上是相当新的），很可能它被编写为使用 NSS 提供的 RSA keygen 函数，Thunderbird 使用的 SSL/TLS 库和火狐。也就是说，该操作实际上并不是特定于 PGP 的，应用程序只需要将已经生成的密钥放入正确的信封中——它没有理由携带几十年前的一些 PGP 特定的密钥生成代码。 （尽管如此，但这并不意味着代码几十年来没有被触及过，例如 NSS 本身及其 Netscape 根源实际上是有史以来最古老的 SSL 库之一。） 另一方面，如果我没记错的话，它带有曾经是 Enigmail 插件一部分的用户界面代码；他们只是将其集成到应用程序中并更换了后端。2000 年代初的一些信息很可能仍然存在。 但总的来说，它速度快有几个原因： 密钥生成算法不像密码散列算法。它的力量并不取决于它的缓慢。生成 RSA 密钥过去很慢，因为 CPU很慢，而且查找素数实际上需要时间。但无论需要多长时间，随机数生成和各种素数测试仍然以完全相同的安全级别实现完全相同的事情。 这在不同程序之间没有太大差异——您可以测试任何处理 RSA 密钥的工具，它们应该给出相同的结果。以稍微过大的密钥大小为例，像openssl genrsa 8192（使用 OpenSSL）或certtool -p --bits=8192（GnuTLS）这样的东西在 ~2005 Celeron CPU 上确实需要超过一分钟，但在 ~2012 Xeon 上只需要大约 8 秒。 （OpenSSL 也“相当古老”，与 NSS 一样古老，但它每天都用于在网络上创建绝大多数 TLS 证书及其密钥对。） 普通随机数生成器实际上已经变得更好（使用更快、更容易理解的新算法），但更重要的是，它们也更容易获得——过去程序必须自带随机数生成器并负责收集来自可疑来源的熵（如 Unix 中的“熵收集守护进程”，或 PuTTYgen 至今仍在使用的“摇晃鼠标 10 秒”的东西），现在每个操作系统本身都提供了一个 CSPRNG，应用程序可以在需要时立即调用随机数据. 我们现在拥有更广泛的非对称密钥算法，它们根本不基于巨大的素数——如果您选择此选项，生成 ECDSA 密钥的方式与生成 RSA 密钥完全不同，而且确实是设计使然比 RSA 快得多。（在相同级别的安全性下，密钥也短得多。）
Crypto.SE 或 Security.SE 将能够提供比我更好的来源答案（我不从事密码学工作），但是：
关于具体实现，如果您使用的是最新的具有内置 OpenPGP 支持的 Thunderbird（这实际上是相当新的），很可能它被编写为使用 NSS 提供的 RSA keygen 函数，Thunderbird 使用的 SSL/TLS 库和火狐。也就是说，该操作实际上并不是特定于 PGP 的，应用程序只需要将已经生成的密钥放入正确的信封中——它没有理由携带几十年前的一些 PGP 特定的密钥生成代码。
（尽管如此，但这并不意味着代码几十年来没有被触及过，例如 NSS 本身及其 Netscape 根源实际上是有史以来最古老的 SSL 库之一。）
另一方面，如果我没记错的话，它带有曾经是 Enigmail 插件一部分的用户界面代码；他们只是将其集成到应用程序中并更换了后端。2000 年代初的一些信息很可能仍然存在。
但总的来说，它速度快有几个原因：
密钥生成算法不像密码散列算法。它的力量并不取决于它的缓慢。生成 RSA 密钥过去很慢，因为 CPU很慢，而且查找素数实际上需要时间。但无论需要多长时间，随机数生成和各种素数测试仍然以完全相同的安全级别实现完全相同的事情。
这在不同程序之间没有太大差异——您可以测试任何处理 RSA 密钥的工具，它们应该给出相同的结果。以稍微过大的密钥大小为例，像
openssl genrsa 8192（使用 OpenSSL）或certtool -p --bits=8192（GnuTLS）这样的东西在 ~2005 Celeron CPU 上确实需要超过一分钟，但在 ~2012 Xeon 上只需要大约 8 秒。（OpenSSL 也“相当古老”，与 NSS 一样古老，但它每天都用于在网络上创建绝大多数 TLS 证书及其密钥对。）
普通随机数生成器实际上已经变得更好（使用更快、更容易理解的新算法），但更重要的是，它们也更容易获得——过去程序必须自带随机数生成器并负责收集来自可疑来源的熵（如 Unix 中的“熵收集守护进程”，或 PuTTYgen 至今仍在使用的“摇晃鼠标 10 秒”的东西），现在每个操作系统本身都提供了一个 CSPRNG，应用程序可以在需要时立即调用随机数据.
我们现在拥有更广泛的非对称密钥算法，它们根本不基于巨大的素数——如果您选择此选项，生成 ECDSA 密钥的方式与生成 RSA 密钥完全不同，而且确实是设计使然比 RSA 快得多。（在相同级别的安全性下，密钥也短得多。）