More strange GPG behavoir

[Werner Koch]

Jason Gunthorpe <jgg at ualberta.ca> writes:

> Someone has sent me this odd message that I can verify using PGP, but
> using GPG fails every time :< I have a attached a small tar.gz file that
> contains the message and it's detached ascii armoured signature, and the

Thanks for the tar file.  I have anylzed it and it turns out to be BUG
#1 - I have now tracked it down:


Here is what PGP 2.6.3in hashes:

MDfile0_len:  43 6F 6E 74 65 6E 74 2D 54 72 61 6E 73 66 65 72
	      2D 45 6E 63 6F 64 69 6E 67 3A 20 71 75 6F 74 65
	      64 2D 70 72 69 6E 74 61 62 6C 65 0D 0A 0D 0A 66
	      6F 6F 0D 0A
MD_addbuffer: 01 37 40 08 27
MDfile0_len:  43 6F 6E 74 65 6E 74 2D 54 72 61 6E 73 66 65 72
	      2D 45 6E 63 6F 64 69 6E 67 3A 20 71 75 6F 74 65
	      64 2D 70 72 69 6E 74 61 62 6C 65 0D 0D 0A 0D 0D
	      0A 66 6F 6F 0D 0D 0A
MD_addbuffer: 01 37 40 08 27

This is what GnuPG hashes:

	      43 6F 6E 74 65 6E 74 2D  54 72 61 6E 73 66 65 72
	      2D 45 6E 63 6F 64 69 6E  67 3A 20 71 75 6F 74 65
	      64 2D 70 72 69 6E 74 61  62 6C 65 0D 0A 0D 0A 66
	      6F 6F 0D 0A
	      01 37 40 08 27

As you can see, PGP first tries the same as GnuPG but then it
hashes an extra CR which yields a valid signature.

It is not easy to implement this strange behaviour with GnuPG because
we can't rewind the input data.  The solution I can see is to add
an extra hash context so that both versions get hashed.  

I can't make a promise to implement that.  


-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013