[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with calculating signatures over keys



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