gnupg - pgp reading signed files

[Johan Wevers]

I dived a little bit further into the pgp2 signing issue. It seems that
GnuPG can't even verify its own output sometimes. When I sign a file with:

gpg --sign --local-user 0x0116CEC9 --rfc1991 --digest-algo md5 --output
test.pgp test.txt

I get a file test.pgp. When I try to verify this file it fails:

gpg --verify Test.pgp
gpg: old style (PGP 2.x) signature
gpg: can't handle this ambiguous signature data

I'm using gnupg 1.4.18.

During a discussion on sci.crypt someone analysed the files and found
out the packet order is incorrect:

> Here is a hex dump of the same file signed with GnuPG using the command
>
> gpg --sign --local-user bontchev --rfc1991 --digest-algo md5 --output
Test.pgp Test.txt
>
> 00: a3 01 01 b7 00 48 ff ac 1d 62 08 54 65 73 74 2e  £..·.Hÿ¬.b.Test.
> 10: 74 78 74 53 c7 ca 4a 54 68 69 73 20 69 73 20 61  txtSÇÊJThis is a
> 20: 20 74 65 73 74 2e 89 00 95 03 05 00 53 c7 ca 4a   test.......SÇÊJ
> 30: 36 56 97 c6 32 dd 98 d9 01 01 e9 b4 04 00 cc 4e  6V.Æ2Ý.Ù..é´..ÌN
> 40: e3 53 12 6e 23 0e f3 4e 59 e3 73 df dd f2 a7 37  ãS.n#.óNYãsßÝò§7
> 50: 26 a8 f6 65 d5 c2 15 cf 5d 53 81 20 91 a6 ce d9  &¨öeÕÂ.Ï]S. '|ÎÙ
> 60: da 4d cc bc d3 d9 da 1a 5a 72 04 42 fa 65 86 91  ÚMÌ 1/4
ÓÙÚ.Zr.Búe.'
> 70: 5c 7d 0e 73 03 87 ac d7 24 e3 71 53 57 13 37 17  \}.s..¬×$ãqSW.7.
> 80: 72 67 51 11 cc ec a4 70 c4 03 36 34 9b 38 35 8a  rgQ.Ìì¤pÄ.64.85.
> 90: 3c 4b cb 83 a1 20 87 dc 50 55 d3 a8 23 7a 3f 9a  <KË.¡ .ÜPUÓ¨#z?.
> a0: 1f d1 8f 9e 46 3b 0a e7 98 d6 7a 43 8b e6 a8 65  .Ñ..F;.ç.ÖzC.æ¨e
> b0: c1 d9 96 19 3f 45 60 28 62 f7 ca 83 64 79        ÁÙ..?E`(b÷Ê.dy
>
> As I wrote earlier, GnuPG *itself* is unable to process this (second)
file. PGP 2.x does not complain about it - but does not verify the
signature, either. Both programs have absolutely no problem with the
first file. The obvious difference between the two files is in the order
of packets - the second file has the literal packet containing the file
name and the file itself at the very beginning, while the first file has
it at the end, after the signature packet.
>
> So, I took a hex editor, cut the literal packet from the beginning of
the second file and pasted it at the end. The result looks like this:
>
> 00: a3 01 01 b7 00 48 ff 89 00 95 03 05 00 53 c7 ca  £..·.Hÿ......SÇÊ
> 10: 4a 36 56 97 c6 32 dd 98 d9 01 01 e9 b4 04 00 cc  J6V.Æ2Ý.Ù..é´..Ì
> 20: 4e e3 53 12 6e 23 0e f3 4e 59 e3 73 df dd f2 a7  NãS.n#.óNYãsßÝò§
> 30: 37 26 a8 f6 65 d5 c2 15 cf 5d 53 81 20 91 a6 ce  7&¨öeÕÂ.Ï]S. '|Î
> 40: d9 da 4d cc bc d3 d9 da 1a 5a 72 04 42 fa 65 86  ÙÚMÌ 1/4
ÓÙÚ.Zr.Búe.
> 50: 91 5c 7d 0e 73 03 87 ac d7 24 e3 71 53 57 13 37  '\}.s..¬×$ãqSW.7
> 60: 17 72 67 51 11 cc ec a4 70 c4 03 36 34 9b 38 35  .rgQ.Ìì¤pÄ.64.85
> 70: 8a 3c 4b cb 83 a1 20 87 dc 50 55 d3 a8 23 7a 3f  .<KË.¡ .ÜPUÓ¨#z?
> 80: 9a 1f d1 8f 9e 46 3b 0a e7 98 d6 7a 43 8b e6 a8  ..Ñ..F;.ç.ÖzC.æ¨
> 90: 65 c1 d9 96 19 3f 45 60 28 62 f7 ca 83 64 79 ac  eÁÙ..?E`(b÷Ê.dy¬
> a0: 1d 62 08 54 65 73 74 2e 74 78 74 53 c7 ca 4a 54  .b.Test.txtSÇÊJT
> b0: 68 69 73 20 69 73 20 61 20 74 65 73 74 2e        his is a test.
>
> Note that is not absolutely identical to the first file. This is
because the signature was created at a later time and the timestamp in
it is different.
>
> Surprise! Neither PGP 2.x, nor GnuPG have any problems processing this
file and verifying its signature.
>
> Conclusion: GnuPG's support of RFC1991 is not compatible with PGP 2.x
(or even with GnuPG itself!) - it outputs the packets in the wrong
order. If this order is corrected, the result will become compatible
with both programs.
>
> The reason for this incompatibility is probably because GnuPG tries to
be way too smart for its own good and to do everything in one pass,
streaming from input to output. The signature is not known before the
whole file has been processed. So, GnuPG first stores the file itself,
while processing it to compute the signature, and when everything is
ready, it appends to the output, after the file, the already computed
signature. It might be a much more elegant approach, but the result is
something that simply doesn't work.


Is there any chance of solving this issue or is rfc1991 considered
abandoned?

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html