RSASSA-PKCS1-v1_5是推荐人们在新系统中使用的良好签名方案吗？我相信RSA-PSS是一种较新的签名方案，也已在PKCS＃1中进行了标准化，它是否被认为是安全的并且代表了基于RSA的签名中的最新技术？我从RSA找到了一份备忘录，建议人们过渡到RSA-PSS。是对的吗？最好建议人们使用RSA-PSS，而不是RSA-PKCS1-v1_5？如果您要建议一个基于RSA的签名方案，那么您会建议新系统使用它吗？

实用意义：例如，目前，WebCryptoAPI的当前草案建议支持RSASSA- PKCS1-v1_5（但不是RSA-PSS）。

评论

不要混淆RSASSA-PKCS1-v1_5（签名系统）和RSAES-PKCS1-v1_5（加密系统），这一点非常重要。后者在实践中很破损。不要使用RSAES-PKCS1-v1_5！

#1 楼

PSS难以实现，因为它使用了随机性-在许多嵌入式系统（如智能卡）上，随机性都很难。

PSS的最广为人知的优点是它具有“安全证明”，显然，它具有减少幅度相当大（请参阅此页面以获取一些参考）。安全证明并非易事。 Shoup发现OAEP的证明（类似于PSS的“姐妹协议”的加密填充）是错误的，然后由Fujisaki，Okamoto，Pointcheval和Stern再次进行了修复，尽管在密封性方面存在一些伤亡。我不知道所有这些都扩展到PSS，但是它表明，安全证明（无论多么酷）可能还需要传统上建立密码安全性的“同行审查”。

关于另一方面，v1.5签名在“野外”暴露的时间是PSS的两倍，并且一直保持不变。在我看来，这非常好，并且我非常相信这种安全性。

从实用的角度来看，使用签名算法意味着使用知道该算法的密钥存储设备（智能卡， HSM，软件实现...）。选择不一定取决于请求签名的应用程序。

评论

$ \ begingroup $
的确如此。在一个典型的设置中，我会比对RSASSA-PKCS-v1_5的攻击更担心边信道对实现的攻击，模因数分解和对哈希的攻击。只有对手获得了许多选定消息的签名（这很不寻常），我才看到可能会出现新的攻击的最小实际风险，例如在此设置中针对ISO / IEC 9796（-1）和ISO的某些攻击/ IEC 9796-2方案1。
$ \ endgroup $
–fgrieu♦
2012年9月21日下午5:56
$ \ begingroup $
需要特别注意的是，在没有随机性的情况下使用PSS时，它不会损坏，安全性降低的程度也越来越小。
$ \ endgroup $
– CodesInChaos
2012年12月30日在16:01
$ \ begingroup $
如果存在随机性问题，可以通过用$ \ operatorname {HMAC}（\ text {private key}，H（M ））$。由于$ H（M）$是RSASSA-PSS的一部分，因此开销是恒定的。证明草图：对于一个不知道私钥的人，如果$ \ operatorname {HMAC} $和$ H $是安全的，则修改后的方案与RSASSA-PSS并无区别，并补充了一个可缓存所有先前提交的RSASSA-PSS签名的gnome。信息;如果RSASSA-PSS是，则该gnome补充的签名方案是安全的。
$ \ endgroup $
–fgrieu♦
2017年9月1日15:56


#2 楼

答案是“否”或“取决于”。

通常来说，RSA-PSS更加强大，因为您不必为了安全地使用它而采取许多额外的预防措施。预先存在的软件广泛支持RSA-PKCS＃1-v1.5 OTOH，但是有时您必须对使用方式进行打补丁，以防止被利用。例如，如果您将RSA-PKCS＃1-v1.5与MD5或SHA1哈希算法配合使用，并对最初从第3方发送给您的数据进行签名，则必须向将要添加的数据中添加大量随机数据签名以防止碰撞攻击。如果您使用RSA-PSS，则没有必要。

1998年，Bellare和Rogaway最初将EMSA-PSS提交给IEEE P1363（基于同一作者的1996年论文），编码将掩码生成函数G作为参数。在本规范中，消息M被作为输入，并且生成了一个新的随机20字节字符串种子。生成20个八位字节的摘要w = G（seed || M），并将该w依次用于生成掩码。

在EMSA4的最终IEEE P1363规范以及PKCS中在RSASSA-PSS的＃1 v2.1规范中，输入是消息的摘要，而不是消息本身，这使算法容易受到基础哈希函数中冲突的影响，但OTOH允许种子长度可参数化。 br />

评论

$ \ begingroup $
我认为PSS不会使您摆脱非抗冲突的哈希函数。使用PSS，第一步是按照给定的消息散列消息（不添加任何不可预测的盐）。而以下操作仅适用于哈希，而不适用于原始消息。因此，如果此哈希函数不是抗冲突的，则PSS签名操作也不会。
$ \ endgroup $
–雨披
2012-09-20 23:06


$ \ begingroup $
@HenrickHellstroöm：您指的是在消息开头添加随机性，以增强MD5或SHA抵御冲突攻击的能力。正如poncho所说，这并不是支持RSA-PSS的理由。
$ \ endgroup $
–fgrieu♦
2012年9月21日在6:07
$ \ begingroup $
实际上，Rogway和Bellare最初提出的PSS提议包括一种不同的哈希机制，该机制将摘要计算为Hash（padding || salt || M）。后来在PKCS＃1 v2.1中对此进行了更改，但是该算法通常称为RSASSA-PSS。
$ \ endgroup $
–亨里克·赫尔斯特伦
2012年9月21日在6:39
$ \ begingroup $
@HenrickHellström：啊，我不知道。仅了解PKCS＃1v2.1中的RSASSA-PSS，它首先对消息进行哈希处理。我现在明白你的意思了。我在您的答案中将RSA-PSS读为RSASSA-PSS，并在我的评论中将前者用作后一种。也许您可以在答案中包含RSA-PSS的描述（一个好处是它可以让我修改我的投票）。
$ \ endgroup $
–fgrieu♦
2012年9月21日7:13


#3 楼

我将不添加任何分析，而只是添加一些有关RSA签名（“带有附录的签名方案”），PKCS＃1 v1.5和PSS（“概率签名方案”）的RFC引用和时间表。

2003年2月鼓励用户远离RFC 3447 PKCS＃1：RSA v2.1，§8：带有附录p的签名方案中的RSASSA PKCS＃1 v1.5。 36


本文档中指定了两个带有附录的签名方案：RSASSA-PSS和RSASSA-PKCS1-v1_5。尽管尚不知道针对RSASSA-PKCS1-v1_5的攻击，但是为了提高鲁棒性，建议将RSASSA-PSS最终用于新应用中。包含RSASSA-PKCS1-v1_5是为了与现有应用程序兼容，并且尽管仍然适用于新应用程序，但鼓励逐步过渡到RSASSA-PSS。 [Emph。已添加]


2016年11月，RFC 8017 PKCS＃1：RSA v2.2，§8：带附录的签名方案，第80页不推荐使用RSASSA PKCS＃1 v1.5。 32，并且PSS被声明为“必需”。


本文档中指定了两个带有附录的签名方案：RSASSA-PSS和RSASSA-PKCS1-v1_5。尽管尚无针对RSASSA-PKCS1-v1_5的攻击，但是为了提高鲁棒性，在新应用中需要使用RSASSA-PSS。仅包含RSASSA-PKCS1-v1_5是为了与现有应用程序兼容。 RSASSA-PKCS1-v1.5和RSAES-PKCS1-v1.5可能有几次。包括在内是为了使他们受益。

用于加密的PKCS＃1 v1.5已弃用20年。

1998年10月，RSAES PKCS＃1 v1.5已发布。在RFC 2437 PKCS＃1 RSA v2.0中，第§7加密方案中已弃用。 11代替RSAES-OAEP。 （在RFC 3447中重复了相同的措词）



RSAES-OAEP建议用于新应用程序；仅包含RSAES-PKCS1-v1_5是为了与现有应用程序兼容，不建议将其用于新应用程序。


2016年11月RFC 8017，第8节：加密方案，第1页。 17带来了一些更强的用语。仅包含RSAES-PKCS1-v1_5是为了与现有应用程序兼容。