On Sat, 9 May 1998, William H. Geiger III wrote:
In
<98May9(_dot_)191656edt(_dot_)43009(_at_)brickwall(_dot_)ceddec(_dot_)com>,
on 05/09/98
at 07:16 PM, dontspam-tzeruch(_at_)ceddec(_dot_)com said:
On Sat, 9 May 1998, William H. Geiger III wrote:
I take it you compressed a zero-byte file? The problem is a bug in PGP
signing zero byte files, where instead of doing something right, it does
what you show above, and something more (read on).
No I did not. I used a small 7 byte text file (test.txt) that contained:
hello<cr><lf>
It was signed with my 1024 RSA key0xFE68B861.
And worked (but see below):
./opgp -i test.pgp -r geiger.pgp #your PKpacket was saved as geiger.pgp
good signature
hello
Or, to show more clearly:
./opgp -i test8.pgp -r geiger.pgp | hd
good signature
000000 68 65 6c 6c 6f 0d 0a
You must inflate (to /dev/null if needed or simply dump the stuff in the
output buffer) as the only way to know where the compressed data ends.
So I have to dump the entire file to the Inflate() function and then
re-parse the packets after inflation? Not a very pretty solution.
Yes, this is ugly, but generally compressed packets are standalone.
Unless the implementation is broken, which it appears to be.
This is a bug in PGP since if you have even one byte of data, what would
be compressed would be sig,literal(data).
Well I don't know if I would call it a bug since this is how both 2.6.x &
5.0 generate this file using RSA key for signing.
The versions I used (Linux 2.6.2 at least) didn't. They did a compressed
packet containg a signature packet followed by a literal packet after
decompression. I just tried it again with an earlier linux verison and it
did the same thing that yours did, i.e. tacked a null compressed packet
before a sig and a literal.
I have attached a copy of the file here, my key is available off the
keyservers if anyone want's to use it to verify the sig block. test.pgp is
hello<lf><cr> signed with 2.6.3a and test8.pgp is the same file signed
with 5.0i.
test.pgp Hexdumped:
000000 a3 01 01 af 00 50 ff
89 00 95 03 05 00 35 53 e7
000010 86 8f 42 a3 59 fe 68 b8 61 01 01 ba 5b 03 fd 12
000020 08 cd 04 e4 e3 1e 04 8c c0 df 07 52 8f f6 a3 35
000030 dd 99 c2 57 86 98 17 07 fb 55 d6 a3 3f 61 44 cd
000040 92 85 3e 1c 0d 09 61 0e b3 1e 66 9e dc 77 b1 7d
000050 59 57 f2 3e 6a 1b d1 ed d2 87 06 57 bf 16 5d 57
000060 34 f3 58 39 9e c7 f9 f0 59 63 4a 34 19 20 10 0f
000070 af 1d cd 98 be 37 64 6c e9 62 39 1c 94 46 e6 cd
000080 9d e0 32 d6 cf 30 9e 1c a6 54 56 bd 4b b9 20 a7
000090 30 cb d2 7d 43 9e da 2a 8a 9c 5a 22 5d 64 95
ac
0000a0 15 62 08 74 65 73 74 2e 74 78 74 00 00 00 00 68
0000b0 65 6c 6c 6f 0d 0a
AC (at byte 0x99) is a literal packet, 15 bytes total, of type Binary
('b'), filename is 8 bytes long: "test.txt", the time dword is zero, and
the contained text is your "hello\r\n".
Since the timestamp differs, and is hashed the two packets will have a
differing signature, but the test8.txt file has the same format.