RSASSA-PSS和RSASSA-PKCS1-之间的切换v1_5注意其他参数吗？

Question

我不确定我是应该在这里问这个问题，还是在安全交换中问这个问题。

无论如何，我最近正在使用TPM处理RSA签名，遇到了一个问题，我将填充方案从RSASSA-PKCS1-v1_5切换到RSASSA-PSS。我认为这应该不会有什么不同，但我注意到一个例子在TSS. MSR（。NET TPM库）不再起作用。我在https://github.com/microsoft/TSS.MSR/issues/109.就开始讨论这个问题了

但我想检查一下，是否有人可以分享观点，是否有必要做或注意一些明显的事情，而不是改变填充方案？

我认为不是，这也隐含在参数中，例如。NET RSA库，例如。https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsasignaturepadding以及如何像这样使用它

using(var rsaKey = RSA.Create(keySizeInBits: 2048))
{
   byte[] message = /* Random data. */
   var sig = rsaKey.SignData(message, HashAlgorithmName.SHA256, RSASignaturePadding.Pss);
}

我从中的问题中看出https://security.stackexchange.com/questions/183179/what-is-rsa-oaep-rsa-pss-in-simple-terms, https://crypto.stackexchange.com/questions/77881/are-rsa-pss-parameters-standardized在其他地方，填充实际上是如何发生的更为复杂。但假设它是库的一个实现细节，并且签名检查似乎不匹配或不起作用，那么一个结论是可能需要检查这个TSS中的各种内部参数。NET库，例如填充。因此，我想确保我自己这个结论是正确的，可能没有什么非常明显的东西。举个例子：不要使用SHA-256，也不要显式地将salt大小设置为nn（好的，这可能是一个通常不应该关心的实现细节）。

增编：

这是在接受了Maarten Bodewes的优秀笔记后写的。

在链接的示例中，将哈希从SHA-256切换到SHA-1并没有消除验证签名的失败。不过，正如所料，“名称化”或摘要更改为20字节。因此，如果在示例或库中的某个地方有一些“延迟默认值”没有得到正确处理，那么这本身（可能是部分解决方案）并不是切换到RSASSA-PSS填充方案失败的原因。

探索仍在继续。：）

Answer 1

实际上，填充有一些配置选项，在使用函数时确实需要提前建立这些选项。

奇怪的是，这些“选项”在标准中没有针对PSS功能进行描述。但是，它们是针对PSS填充机制列出的：

Options:

  Hash     hash function (hLen denotes the length in octets of the hash
           function output)
  MGF      mask generation function
  sLen     intended length in octets of the salt

然而，这仍然不能完全配置PSS，因为MGF本身是一个算法，该算法也有参数。

因此，最好查看参数的ASN.1结构，以获得一个好主意：

RSASSA-PSS-params ::= SEQUENCE {
   hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
   maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1,
   saltLength         [2] INTEGER            DEFAULT 20,
   trailerField       [3] TrailerField       DEFAULT trailerFieldBC
}

幸运的是，只有一个掩码生成函数：MGF1。也只指定了一个预告片字段：trailerFieldBC，所以这主要是为未来的更改指定的。

如您所见，其中有两个哈希函数，一个用于消息/输入数据本身，另一个用于掩码生成函数（MGF）。因此，哈希值又是MGF1的一个配置参数。该标准指出，最好对消息哈希和MGF1哈希使用相同的哈希函数。但是，算法可能会使用默认值，正如您在结构中看到的，它是SHA-1。另外，Java总是将SHA-1用于MGF1，但是。NET使用与消息哈希相同的哈希。

类似地，通常将盐长度设置为hLen，即散列的输出大小。默认值为20，但这是因为这是SHA-1的输出大小。0的值也是一个选项，但我认为一般留到20。

因此，是的，不幸的是，您确实需要检查是否使用了相同的参数。一个好的库应该清楚地指定使用什么，或者至少可以选择显式地配置它们。然而，如果这是一个好的库的要求，那么就存在许多坏的库。此外，您绝对不应该试图从签名本身获取此类信息，也不应该在验证过程中猜测多个算法，因为这会将安全性降低到可能的最低安全算法。

最后，当您找到一个安全且兼容的PSS方案时，我建议您在代码中明确指定使用哪组参数。这可以使用显式参数完成（即使默认值用于特定库）。如果不可能在注释中指定参数，也可以在注释中指定参数。单独记录您的计划并在评论中指出它不会有什么坏处。