出于安全考虑,RSA 公共指数是否应该仅在 {3、5、17、257 或 65537} 中?

信息安全 密码学 加密 密码分析
2021-08-30 05:25:39

在我的项目中,我使用了 4451h 的公共指数值。在我开始使用一个商业 RSA 加密库之前,我认为它是安全且可以的。如果我在这个库中使用这个指数,它会抛出异常。

我联系了这个库的开发者,得到了如下回复:“这个功能是为了防止对 RSA 密钥的一些攻击。结果是指数值被限制为 {3,5,17,257 或 65537}。停用此检查是仍在调查中,因为风险可能很大。”

这是我有生以来第一次听说使用 {3、5、17、257 或 65537} 以外的值来破坏 RSA。我只知道使用不正确填充的 3 很容易受到攻击。

真的是这样吗?当然,我可以使用另一个库,但在这样的回答之后,我担心我的解决方案的安全性。

4个回答

RSA 的任何短或长公共指数都没有已知的弱点,只要公共指数是“正确的”(即,对于除模的所有素数p ,与p-1相对素数)。

如果您使用一个小指数并且您不使用任何填充进行加密并且您使用几个不同的公钥加密完全相同的消息,那么您的消息就有风险:如果e = 3 ,并且您使用公钥n 1加密消息m , n 2n 3,那么你有c i = m 3 mod n i for i = 1 to 3根据中国剩余定理,你可以重建m 3 mod n 1n 2 n 3,结果是m 3(没有任何模数),因为 n 1 n 2 n 3是一个更大的整数。(非模块化)立方根提取然后足以提取m

这里的弱点不是小指数。相反,它是使用不适当的填充(即根本没有填充)进行加密。填充对于 RSA 的安全性非常重要,无论是加密还是签名;如果您不使用适当的填充(例如PKCS#1中描述的那些),那么您有很多弱点,并且到目前为止,上一段中概述的那个并不是最大的。然而,每当有人提到与指数大小相关的弱点时,他或多或少直接提到了这种情况。这有点陈旧且不正确的传说,有时会被倒置为禁止指数(因为它是一个神话,反向神话也是一个神话,没有更多——也没有更少——被证实);我相信这就是你在这里观察到的。

但是,我们可以找到一些为什么要避免使用大的公共指数的原因:

  • 小公共指数提高效率(用于公钥操作)。

  • 有一个小的私有指数存在安全问题;当私有指数长度不超过公共指数长度的 29% 时,已经描述了密钥恢复攻击。当你想强制私有指数变短(例如加快私有密钥操作)时,你或多或少必须使用一个大的公共指数(与模一样大);要求公共指数做短可以被视为一种间接对策。

  • 一些广泛部署的 RSA 实现在大型 RSA 公共指数上窒息。例如,Windows 中的 RSA 代码(CryptoAPI,Internet Explorer 用于 HTTPS)坚持将公共指数编码在单个 32 位字中;它无法处理具有更大公共指数的公钥。

尽管如此,“风险可能很大”看起来像一般的理由(“这是一个安全问题”是说“我们没有实施它但我们不想承认任何懒惰”的常用方式)。

这五个数字是费马素数

由于它们的形式为 2 k + 1,因此加密为m e = m ·(( m 2 ) 2 ... k...) 2,这比在一般情况

因为它们是素数,所以e与 ( p − 1)( q − 1)互质的检验只是e不整除它的检验。

所以这更有可能是关于速度或惯例而不是关于安全性。并不是说效率有什么问题。但可以肯定的是,请按照其他答案的建议寻求参考。

另见这篇文章

开发人员根本不正确。指数 0x4451(十进制 17489)没有问题;它不会产生任何安全问题。

很久以前,人们曾经认为小指数是个问题,因为 Thomas Pornin 解释说向多个收件人发送相同的消息时发生的攻击。但是今天我们知道指数与它无关。问题是填充不当。正确使用填充可以防止这些攻击。任何有价值的加密库都最好使用适当的填充(否则你会遇到更糟糕的问题)。

因此,加密库没有充分的理由断然禁止使用该指数。

也就是说,从性能的角度来看,指数越小,性能越好。最好的选择是 e=3,因为它提供了最好的性能并且没有已知的安全问题。(其实e=2还要好一点,也叫拉宾加密,不过这种方案知名度不高,代码略有不同,所以没有广泛使用。)

我不知道为什么 RSA 密钥的公共指数只能在集合 {3,5,17,257,65537} 中。正如您所提到的,使用 3 或 5 之类的小指数风险更大,因为实现错误(例如不正确的填充)的负面影响可能更大。NIST 只允许大于 2^16 的公共指数,但我不知道他们决定的原因。

您不应该对您使用的库的开发人员给出的答案感到满意,并要求提供具体的参考。很多时候,事实证明有些论文被误解了。例如,我可以想象一些开发人员阅读了 Phong Nguyen 的论文“我们可以信任加密软件吗?GNU Privacy Guard v1.2.3 中的加密缺陷”的第 4 节,并得出了一个错误的结论,例如上面的那个。本文注意到,当 GnuPG 生成的公钥是一些不寻常的值(例如 65539)时,攻击者会了解到一些关于密钥的信息。结论是 GnuPG 的密钥生成算法可以改进,但不能说 65539 ​​是一个坏公钥。