RFC 4880描述了版本4签名包,标记2,as
- 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(从版本号散列数据包括在内),但仍无法找到散列为正确的值的字符串
当您生成签名包时，它始终是某人对某些内容的签名。也就是说，有一些正在签名的数据和公钥，而签名的要点是它只能由拥有确切数据和相应私钥的人来制作。
因此，“正在签名的数据”将是该数据块恰好是什么。有关一些示例，请参阅 RFC4880 第 5.2.1 节。在本例中，您可能对公钥块内的签名数据包感兴趣。
第一个是“用户 ID 和公钥数据包的肯定认证（0x13）”。RFC4880 的 5.2.4 节对此进行了描述。
第二个是“子密钥绑定签名”，主密钥（DSA 密钥）由此保证子密钥（仅 ElGamal 加密）属于它。RFC4880 的 5.2.4 节中也描述了其工作方式。
以下是 5.2.4 中的相关文本：
当对密钥进行签名时，哈希数据以八位字节 0x99 开始，后面是两个八位字节长度的密钥，然后是密钥数据包的正文。（请注意，这是具有两个八位字节长度的密钥数据包的旧式数据包标头。）子密钥绑定签名（类型 0x18）或主密钥绑定签名（类型 0x19）然后使用与主密钥相同的格式对子密钥进行哈希处理key（也使用 0x99 作为第一个八位字节）。密钥撤销签名（类型 0x20 和 0x28）仅对被撤销的密钥进行哈希处理。
进而
认证签名（类型 0x10 到 0x13）将绑定到密钥的用户 ID 哈希到上述数据之后的哈希上下文中。V3 认证对用户 ID 或属性数据包的内容进行哈希处理，不带任何标头。V4 认证对用户 ID 认证的常量 0xB4 或用户属性认证的常量 0xD1 进行哈希处理，后跟给出用户 ID 或用户属性数据长度的四个八位字节数字，然后是用户 ID 或用户属性数据。