RSA-PSS DB MSB可以是1吗？

Question

我用OpenSSL生成了一个RSA键盘。

-----BEGIN PRIVATE KEY-----
MIIBUgIBADALBgkqhkiG9w0BAQoEggE+MIIBOgIBAAJBAKjJmhflBebbRJt0JNWe
elk9w32jGxvZrvxO7kdpvNFWCgXIXSU0zC26R2Rca1w81sY4MpKfKl0baIK06Dbp
F6cCAwEAAQJANfamrocJeQKXj7/1WtrdMRT/IHb6XtAdEwvFQM28kYyUU4QuIxGO
cJ90rX99FdhOouUtbeYVXfnR7+I4NL6C+QIhAN6GukudUZqsor+AH/fuVg1Z4cUo
8slDhv5hoHJq1HizAiEAwi1yKT4YeBWc7vxwBwQ5i2DtrhfOxOs1+Mzij7xu1z0C
IQCqekz+4OdDuD52t5HGP7FtSQ7OHTDjP/iLqf9hqLZeQQIgf7DVBuwPuUA1QC9/
GA4eLVrjUf3T+kjW6DMLtgvrM90CIGAwntt2VAvNb2rCNMsLqtkM0iLGGopRkXqW
hkb6wXFX
-----END PRIVATE KEY-----

我正在使用OpenSSL与SHA256签署一条短消息(文本“RSA”)，并手工验证该签名：

$ cat hash_value | openssl pkeyutl -sign -inkey rsapsskey.pem -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:30 >signature

在某些情况下，DB的MSB设置为1，即块以0x80开始，而不是0x00。如果种子填充整个DB，则分离字节0x01变为0x81。例如：

s = 3193b488a362a71b7b1fb4328a3f2eea2423f762a87ad9823b01c21e1fe7296a3d4530513945c8b59f30427fa9c9c60340d20320d10a0f21290669060b833b83

s^e \mod n = 64f252e4a9dc625f881b87010ab54c5dc557fac18ff11573621e92aa68415067c12e5a3c85aafe33c90a7fd352ddb5c0dcada72268c55d74cc034fe9ff54b9bc

mDB = 64f252e4a9dc625f881b87010ab54c5dc557fac18ff11573621e92aa684150

掩码= e58271cfa607b848676d08342483e8e57aee64c76853f2a09944f6a731d2a7

DB = 8170232b0fdbda17ef768f352e36a4b8bfb99e06e7a2e7d3fb5a640d5993f7

种子= 70232b0fdbda17ef768f352e36a4b8bfb99e06e7a2e7d3fb5a640d5993f7

m' = 000000000000000068c8e017fdb4880b0b276605be9003f9cb6a9504b8b83edac2ccf9d0de420ca170232b0fdbda17ef768f352e36a4b8bfb99e06e7a2e7d3fb5a640d5993f7

H(m') = 67c12e5a3c85aafe33c90a7fd352ddb5c0dcada72268c55d74cc034fe9ff54b9

也就是说，签名验证是可行的，但是为什么DB 0x81的第一个字节不是0x01呢？我在RFC8017中找不到对这种行为的引用。

Answer 1

我将使用PKCS#1v2.2 (RSA实验室版)作为参考。

从带有ASN.1解码器的私钥的角度看，公共模n是512位，因此在RSASSA验证中有modBits\,=\,512，k=64.

因此，在EMSA验证中我们有emBits\,=\,modBits\;-\,1\,=\,511。EM是问题的64-八进制字符串，位于s^e\,\bmod n之后.*emLen\,=\,\lceil\,emBits\,/\,8\,\rceil\,=\,64。hash是SHA-256，因此是hLen\,=\,32.问题的盐是30个八位数，因此是sLen\,=\,30。满足约束emBits\,\ge\,8\,hLen\,+\,8\,sLen\,+\,9 (带有额外的7位)。

在EMSA验证步骤3，emLen\,\ge\,hLen+\,sLen\,+\,2，检查通过。

在步骤4，EM的最右边八进制有十六进制值\text{0xbc}，检查通过。

在步骤5中，maskedDB是最左边的emLen\;-\,hLen\;-\,1\,=\,31八进制，在问题中作为"mDB“。

在步骤6中，它被认为是8\,emLen\;-\,emBits\,=\,1最左边的位(S)，它是maskedDB最左边的八进制。那个八进制是\text{0x64}，那个位是0，检查通过。

在步骤7中，dbMask是这个问题的“掩码”的31个八位数。

在步骤8中，DB是这个问题的"DB“的31个八位数。

在步骤9中，将DB中最左边的八进制的最左边8\,emLen\;-\,emBits\,=\,1位(S)设置为零。最左边的八进制从\text{0x81}到\text{0x01}。

为什么DB \text{0x81}的第一个字节不是\text{0x01}？

第一个字节/最左边的八进制是步骤8之后的\text{0x81}，因为dbMask是在一个足以执行步骤8的异或的整数数目上计算的，如果左八进制在dbMask中取伪随机值(S)，则使用k\,+1\,\bmod\,8\,=\,1额外位(S)，因此在XOR之后的DB中(这恰好是零位，在步骤6中检查)。但是，DB中的这些额外比特(S)在第9步被掩盖为零。

在屏蔽之后，字节是\text{0x01}，因为签名是有效的，而salt已被设置为最大可能大小的k\;-\,hLen\;-\,1。对于任何较小的盐大小，它都是\text{0x00}。

我们现在可以回答标题中的问题：

RSA DB最重要的位数是1吗？

DB的No为计算值

• 在签名生成过程中，在步骤8的EMSA-PSS-ENCODE中；
• 在EMSA验证中，在验证签名的过程中，在步骤9中，如果k\,\bmod8\,\ne\,1 (因为步骤9掩盖了这个最重要的位)或签名是否有效(因为这个最重要的位必须是零，这将在步骤10中检查)；

但对DB来说可能是这样，如在EMSA验证中计算的那样

• 在步骤8(不考虑k的签名有效性和值)，如在问题中；
• 在步骤9中，虽然只适用于无效签名和k\,\bmod8\,=\,1 (例如2049位n)。注意，对于这样的k，步骤9不执行掩蔽，如果最重要的DB位恰好是1，那么步骤10将捕获签名为无效。