Subject: signature woes and reconciliation, examples appreciated

From: [email-masked]
Date: Thu, 31 Jul 2003 23:55:28 +0000

I recently ran into trouble trying to calculate the hash needed to
verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python 
hopeful-implementation-to-be.

From bis-08:

    (V3 sigs)
    5.2.2 The data being signed is hashed, and then the signature type
          and creation time from the signature packet are hashed (5 
          additional octets).  The resulting hash value is used in the
          signature algorithm.
    (sigs in general)
    5.2.4 Once the data body is hashed, then a trailer is hashed.

This led me to assume (+: concatenate):

    h = HASH( data body ) + HASH( trailer ) # based on the above
    final = HASH( h ) # inferred from 160-bit DSA requirement 

..which didn't work, sending me back to Google and eventually to the
GnuPG source. Long source-searching story shortened, I ended up with:

    final = HASH( data body + trailer )

..which didn't feel right, even though it evidently worked for gpg and
definitely worked for me. Things were somewhat reconciled when I found
a file named 'pgpformat.txt' from a PGP 2.x archive:

    pgformat.txt "Signature packet" section:

        Offset Length Meaning

        4       1     Length of following material that is implicitly
                      included in MD calculation (=5).
        5       1     Signature classification field (see below).
                      Implicitly append this to message for MD 
                      calculation.
        6       4     32-bit timestamp of when signature was made.
                      Implicitly append this to message for MD
                      calculation.

    pgformat.txt "Literal data packet, with filename and mode":

        Whne calculating a signature on a literal packet, the signature
        calculation only includes the raw literal plaintext data that
        begins AFTER the header fields..

Probabilities being what they are, I'm going to assume I'm on the
right track and grant myself an attaboy.

Up until this point I had been working *exclusively* with bis-08 and 
had no trouble at all working out packet structure, MPIs, etc.. Code
and pseudo-code examples helped out enormously. Just thought that this
might be one area where something blatantly obvious to the gurus might
leave the wannabes a little perplexed (color me perplexed). 

I suggest adding pseudo code to more (if not all) operations in the 
spec (which I'd be happy to contribute as I continue along).

Aloha,
the poiboy

---

From: "Hal Finney" <[email-masked]>
Date: Thu, 31 Jul 2003 17:15:16 -0700

> From: [email-masked]

I've had someone else run into the same problem interpreting this part of
the spec.  The language about "first you hash this, then you hash that,
then you hash this other thing" seems very natural to me (I wrote much of
it after all), working with a programming interface where you pass data
incrementally into a hash context object.  But other people interpret
it as you did, that you produce a hash of the first part, then a hash
of the second part, then a hash of the third part, and somehow combine
these hashes together to get the final signature.

Hal Finney