Anonymous writes:

This value is wrong: it has 3 bytes of 0's inserted and is therefore missing the last three bytes of the signature.

s = 0x08F4D5CBC10063725B206F787EB7370BBD0C5B4854CE79A9007D1801AEAEE6E6 D2C68D7EDF877FECE1FA539D08BEC54BD152BA05113951E8A84CDECAD2CB8E7A C28BE916570BA7BB9C00C64DF57113C4AE81613BD351541523CD3A028FBF220E F7469BD4175302DCB5B6E886974877F28A2D301433AFFFE26081008BFF687B37

Here is the correct value, from the signed message.

08F4D5CBC10063725B206F787EB7370BBD0C5B4854CE79A97D1801AEAEE6E6D2 C68D7EDF877FECE1FA539D08BEC54BD152BA05113951E8A84CDECAD2CB8E7AC2 8BE916570BA7BB9CC64DF57113C4AE81613BD351541523CD3A028FBF220EF746 9BD4175302DCB5B6E886974877F28A2D301433AFFFE260818BFF687B37DE8167

Hmm! That explains this output of pgpacket which I had already forwarded to Mark Shoulson as a bug in pgpacket: % pgpacket < totopost.asc --------------------------- Packet Type: Secret-Key Encrypted Packet (signature) Length: 149 Version: 3 Adding 5 bytes of header to digest Signature of canonical text document Signature Created: 9 Dec 1997 21:29:02 Signing Key ID: 0xCE56A4072541C535 Public Key Algorithm: 1 (RSA) Message Digest Algorithm: 1 (MD5) Check bytes: 0x5A82 128 bytes of data (1) Data: 08F4D5CBC10063725B206F787EB7370BBD0C5B4854CE79A9007D1801AEAEE6E6D2C68D7E DF877FECE1FA539D08BEC54BD152BA05113951E8A84CDECAD2CB8E7AC28BE916570BA7BB9C00C64D F57113C4AE81613BD351541523CD3A028FBF220EF7469BD4175302DCB5B6E886974877F28A2D3014 33AFFFE26081008BFF687B37 --------------------------- Packet Type: UNKNOWN PACKET!! (36) Length: 129 (No handler known. Skipping 1 bytes) Data: 0x67 I couldn't figure out what the spurious packet was about, you just solved that one... pgpacket is inserting spurious 00s in the message. (I've Cc'ed Mark Shoulson). Adam