5

RFC 4880 将版本 4 签名数据包标签 2 描述为

- One-octet signature type.
- One-octet public-key algorithm.
- One-octet hash algorithm.
- Two-octet scalar octet count for following hashed subpacket data.
Note that this is the length in octets of all of the hashed
subpackets; a pointer incremented by this number will skip over
the hashed subpackets.
- Hashed subpacket data set (zero or more subpackets).
- Two-octet scalar octet count for the following unhashed subpacket
data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets.
- Unhashed subpacket data set (zero or more subpackets).
- Two-octet field holding the left 16 bits of the signed hash
value.
- One or more multiprecision integers comprising the signature.

我假设倒数第二行意味着只取散列子包的字符串并用散列算法对其进行散列并取其前 2 个字节。但是，无论我做什么，我似乎都无法得到它。

我很久以前生成了这个假密钥

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG v1.39

mQGiBE5B0h8RBAD533Z5bK1IpBx02QyQL0QoJE4uFRIMGDiwXuwmZzVl+R7Vlurd
GRLsCCbE6vOOh7XQVZGzLEBy9WNzZ9m+EbCfSVAYkjS6FhLws6hG6irrnS+b3JBf
gFJ8vNGF9Z7bhx+7y7NBk0IMyWkGnUkcnav73t5FQUI2faEBN4c/yAGJZwCgjcB7
3akWk9XVWvTCsiMXxpyvkukEALXsvB6cOoFEtQq9cQHjP63fBlvD94dhhMiM0cH6
hW9JotxdK+cxFGG9ZIWgoN2PWbMJka/H4W5EL6tS+YiNAR7I1Ozkt6X16GjnQUzZ
MlSpleK+KiKVN2anRaPEoOIinHrE3ZXd6QlJ/4+OJn4IVWmSEaJpFf4QNgvEu4rh
xinyBAD2RNzREOA+wpnFZ4lDt9NZXmXdxQME/l0J9XcvWhpGsxA/MATQKImy7N49
7GT/M38F+TrpBobag1O3buE99fOLyws4Tbc+sZMdHxoiGZDAIRNQS2rv475E6ktj
7vd5CYvOkA6+8sX1+hPcNlkHtHB1OFkJRsYp6k0zkyC9adjBM7QTYWJjIDxtYWtj
bUBhYWEuY29tPohGBBMRAgAGBQJOQdIfAAoJEDBSJUXPd92GRSQAoItbtbToOg7a
/hcg2sA/aBEQNwuxAKCGR69vmSoCWoBP5waPk0UsjM3BSbjMBE5B0h8QAgCUlP7A
lfO4XuKGVCs4NvyBpd0KA0m0wjndOHRNSIz44x24vLfTO0GrueWjPMqRRLHO8zLJ
S/BXO/BHo6ypjN87Af0VPV1hcq20MEW2iujh3hBwthNwBWhtKdPXOndJGZaB7lsh
LJuWv9z6WyDNXj/SBEiV1gnPm0ELeg8Syhy5pCjMAf9QHehP2eCFqfEwTAnaOlA6
CU+rYHKPZaI9NUwCA7qD2d93/l08/+ZtFvejZW1RWrJ8qfLDRtlPgRzigoF/CXbR
iEYEGBECAAYFAk5B0h8ACgkQMFIlRc933YZRrACfUnWTjHHN+QsEEoJrwRvFmvzj
bR4An24pTpeeN+I6R59O/sdmYsAhjULX
=sStS
-----END PGP PUBLIC KEY BLOCK-----

我认为我应该做的：

sha1("\x05\x02\x4e\x41\xd2\x1f") = "52f07613cfd61c80d2343566a8f3f487a0975b80"

\x05 - length of subpacket
\x02 - subpacket type
\x4e\x41\d2\x1f - creation time

从pgpdump.net，我看到散列 (SHA 1) 值的左侧 2 个字节45 24用于第一个签名包和51 ac第二个签名包。我得到52 f0了两者。显然，我不包括一些信息，但它是什么？散列后的子包相同，散列数据之前的所有数据也相同，只是它们是不同类型的签名包（0x13 / 0x18）。即使我从数据包中添加/获取字符，我也无法获得任何正确的哈希值。除了哈希值之外，生成的密钥与此处显示的密钥完全相同。

我应该散列的数据是什么？

编辑：如果稍后发现：

The concatenation of the data being signed and the signature data
from the version number through the hashed subpacket data (inclusive)
is hashed. The resulting hash value is what is signed. The left 16
bits of the hash are included in the Signature packet to provide a
quick test to reject some invalid signatures.

但是正在签名的数据是什么？签名前的所有数据包？只是当前签名包之前的包？

上面的关键示例由packet 6 + packet 13 + packet 2 + packet 14 + packet 2. 我已经尝试了各种组合packet 6，，packet 13和packet 2（从版本号到散列数据包括在内），但仍然找不到散列到正确值的字符串

4

1 回答 1

2

当您生成签名包时，它始终是某人对某事的签名。也就是说，有一些数据被签名，还有一个公钥，而签名的意义在于，它应该只能由拥有该确切数据和相应私钥的人制作。

因此，“正在签名的数据”将是任何数据块。有关一些示例，请参见 RFC4880 的第 5.2.1 节。在本例中，大概您对公钥块内的签名包感兴趣。

第一个是“用户 ID 和公钥数据包（0x13）的肯定认证”。这在 RFC4880 的第 5.2.4 节中有所描述。

第二个是“子密钥绑定签名”，主密钥（DSA 密钥）保证子密钥（ElGamal 仅加密）属于它。RFC4880 的第 5.2.4 节也描述了这种工作方式。

以下是 5.2.4 中的相关文本：

当对密钥进行签名时，哈希数据以八位字节 0x99 开始，然后是密钥的两个八位字节长度，然后是密钥包的正文。（请注意，这是具有两个八位字节长度的密钥数据包的旧式数据包标头。）子密钥绑定签名（类型 0x18）或主密钥绑定签名（类型 0x19）然后使用与主密钥相同的格式对子密钥进行哈希处理密钥（也使用 0x99 作为第一个八位字节）。密钥撤销签名（类型 0x20 和 0x28）仅散列被撤销的密钥。

进而

证书签名（类型 0x10 到 0x13）将绑定到密钥的用户 ID 散列到上述数据之后的散列上下文中。V3 认证对用户 ID 或属性数据包数据包的内容进行散列处理，没有任何标头。V4 认证对用于用户 ID 认证的常量 0xB4 或用于用户属性认证的常量 0xD1 进行哈希处理，后跟一个给出用户 ID 或用户属性数据长度的四字节数字，然后是用户 ID 或用户属性数据。

于 2012-06-07T00:00:42.823 回答