Thanks for the clarification, but I still can't get the right resuts. I
tried to calculate like this:
SHA1(0x99 (public key tag)+ 0x01 + 0xA2 (key length) + Key packet (418
bytes) + 0xB4 (user id tag) + 0x00 + 0x00 + 0x00 + 0x28 (user id length) +
User Id packet (40 bytes) + 0x04 + 0x13 + 0x11 + 0x02 + 0x00 + 0x1E + 0x05 +
0x02 + 0x42 + 0x95 + 0x6E + 0xD1 + 0x02 + 0x1B + 0x03 + 0x06 + 0x0B + 0x09 +
0x08 + 0x07 + 0x03 + 0x02 + 0x03 + 0x15 + 0x02 + 0x03 + 0x03 + 0x16 + 0x02 +
0x01 + 0x02 + 0x1E + 0x01 + 0x02 + 0x17 + 0x80 + Trailer: 0x04 + 0xFF + 0x24
(big endian length of hashed data from the sign. packet) + 0x00 + 0x00 +
0x00)
The result I got was 0xfcfc4c8598c9349959eb5cb23321add6b92f2137, so the left
bytes are 0xFC and 0xFC, but in the key the values are 0xE8 and 0xA4.
Kimmo
From: hal(_at_)finney(_dot_)org ("Hal Finney")
To: ietf-openpgp(_at_)imc(_dot_)org, spider-41(_at_)hotmail(_dot_)com
Subject: Re: Problems with calculating signatures over keys
Date: Thu, 26 May 2005 08:34:29 -0700 (PDT)
Kimmo M?kel?inen writes:
> First, how many octets there should be in the user id packet to define
the
> length of the username?
>
> It is said in the 5.2.4 that
> "A V4 certification hashes the constant 0xb4 (which is an
> old-style packet header with the length-of-length set to zero), a
> four-octet number giving the length of the username, and then the
> username data."
>
> However, in the key generated by GnuPG the length is given with only one
> octet. I have used the PGPdump interface (http://www.pgpdump.net) to
> visualize the key data, and the interface shows the data correctly,
> including the user id packet.
The number of octets that is hashed is different from the number that
is used in the packet. For a V4 signature, always 4 octets of length
are hashed. The number used in the packet may be 1, 2 or 4 octets.
You need to pad the octets from the packet with leading 0's to get 4
octets for hash purposes, if fewer are used there.
> In 5.2.4 is also said that
>
> "V4 signatures also hash in a final trailer of six octets: the version
> of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
> number that is the length of the hashed data from the signature
> packet (note that this number does not include these final six
> octets."
>
> I haven't found an unambiguous explanation for the length bytes. Is it
the
> length of the whole data being hashed (from the public key packet
through
> the end of the hashed subpacket data of signature packet) or just from
the
> version number of the signature packet through the end of hashed
subpacket
> data?
It is the latter, it is the number of bytes hashed from the signature
packet starting from the version number and going through the end of
the hashed subpacket data.
You are not the first person to have trouble getting it to work.
Unfortunately it is the nature of cryptographic hashes that making even
the slightest error produces a completely wrong result, with no hint
about how close you are.
We might want to consider some "test vectors" in the RFC which work
through the process of verifying a signature. We'd show the key and
associated packets, and then show the exact sequence of bytes which
gets hashed. I think that would be a big help to implementors.
Unfortunately once we open the door to including such an example,
there are a lot of other things we might need to show. The public key
signature operations themselves, signatures on text and binary messages,
encryption and decryption, encrypt+sign, etc. We could almost use a
separate RFC just with examples as an aid to implementors.
Hal Finney
_________________________________________________________________
Lataa ilmainen MSN Messenger http://messenger.msn.fi