hash - OpenPGP 签名包散列数据

Question

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 个字节。但是，无论我做什么，我似乎都无法得到它。

我很久以前生成了这个假 key

-----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)。即使我从数据包中添加/获取字符，我也无法获得任何正确的哈希值。除了哈希值之外，生成的 key 与此处显示的 key 完全相同。

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

编辑:如果稍后发现:

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 (从版本号到散列数据包括在内)，但仍然找不到散列到正确值的字符串

Answer 1

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

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

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

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

以下是 5.2.4 中的相关文本:

When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet). Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.

进而

A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute packet packet, without any header. A V4 certification hashes the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data.