Subject: Re: Problems with calculating signatures over keys

From: [email-masked] ("Hal Finney")
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

---

From: Derek Atkins <[email-masked]>
Date: Thu, 26 May 2005 12:52:46 -0400

Hal,

<chair hat>

> gets hashed.  I think that would be a big help to implementors.

I agree that this would be a boon to implementors.  Do you want to
volunteer to do this?  :)

> separate RFC just with examples as an aid to implementors.

I also agree that a separate "Test Vectors" draft would be the right
place to put it.  It could even be an informational draft instead of a
standards-track draft, but it could still be called something like:
   draft-ietf-openpgp-test-vectors

> Hal Finney

Are there any objections from the WG to doing this?  As chair I think
it's a good idea and would welcome a test vectors draft.

</chair hat>

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Jon Callas <[email-masked]>
Date: Sat, 28 May 2005 07:51:02 -0700

> it's a good idea and would welcome a test vectors draft.

I'd go so far as to say it should be an implementation hints draft. It 
could include things like Elgamal signatures, as well, and other things 
that doing belong in the standards RFCs.

	Jon

---

From: Kimmo Mäkeläinen <[email-masked]>
Date: Mon, 30 May 2005 14:25:21 +0300

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: [email-masked] ("Hal Finney")
>To: [email-masked], [email-masked]
>Subject: Re: Problems with calculating signatures over keys
>Date: Thu, 26 May 2005 08:34:29 -0700 (PDT)
>
>Kimmo M?kel?inen writes:

_________________________________________________________________
Hotmail vai Hotmail Plus? Tutustu palveluihin. 
http://www.imagine-msn.com/hotmail/fi-fi/

---

From: Kimmo Mäkeläinen <[email-masked]>
Date: Mon, 30 May 2005 14:25:50 +0300

Kimmo

_________________________________________________________________
Lataa ilmainen MSN Messenger http://messenger.msn.fi