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