2012-05-29 42 views
5

RFC 4880描述了版本4签名分组,标签2,如OpenPGP的签名分组哈希数据

- 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,我看到左边的2个字节的散列(SHA 1)的值为第一个签名数据包的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 6packet 13packet 2组合(从版本号散列数据包括在内),但仍无法找到散列为正确的值

回答

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)散列 只有密钥被撤销。

然后

甲认证签名(类型0×10 0×13通过)散列用户ID 被绑定到钥匙插入上述数据后的散列上下文。 A V3认证散列了用户标识或属性 数据包的内容,没有任何标头。 V4证书对 用户ID认证或用户属性数据的长度为 ,然后用户ID或 用户进行用户ID认证的恒定0xB4或用户 属性认证的常量0xD1,后跟4字节的数字属性数据。