Key strangeness

Jason Harris jharris at widomaker.com
Tue Dec 14 19:09:54 CET 2004


On Sun, Feb 08, 2004 at 10:46:58AM -0500, David Shaw wrote:

> A bug in his software (CryptoEx) would explain nearly everything
> here.  Since CryptoEx naturally would be compatible with itself, it
> would see the keyid as 3A546EC2.  It would fill in 3A546EC2 as the
> issuer of signatures, and it would be able to verify its own
> signatures so the key would be valid.
> 
> That theory doesn't explain why the keyservers indexed the key as
> 3A546EC2 though.  GnuPG, PGP 6 and 8, and my local copy of pksd all
> agree the keyid is 7EDB7A47.

[I thought I would have replied to this already, but I don't see any
evidence of having done so.]

diffing the hd(1) output shows differences in the pubkey packet:

19c19
< 00000120  48 52 9b 03 fe 25 75 2a  3f f5 ac 00 50 00 a6 80  |HR...%u*?...P...|
---
> 00000120  48 52 9b 04 00 25 75 2a  3f f5 ac 00 50 00 a6 80  |HR...%u*?...P...|

which pgpdump claims are leading zeroes in an MPI (1022 v. 1024 bits):

8c8
<       DSA y(1022 bits) - 25 75 2a 3f f5 ac 00 50 00 a6 80 f7 76 13 6f b5 12 61 35 9c a9 8a 68 47 75 69 e5 e6 3f e8 9d 52 67 ad ed d7 7e 9e 04 ab e2 29 7e 00 bd 27 a3 c0 7e ea 5d 13 8f bc 67 50 55 5e 82 1d 41 b4 a3 90 39 8a b4 9a 8d 60 ee 63 6b 3c 81 1d 07 6b c4 f1 31 6f 22 84 d2 ae f9 d6 55 46 1f 3c 75 7b 56 30 0a 0a 82 f7 22 3c 0d 77 1b dd ad 53 68 b7 de 5d fe 4c 5a 1f a3 33 fe b6 2f ff 3a 22 86 f2 21 ff 
---
>       DSA y(1024 bits) - 25 75 2a 3f f5 ac 00 50 00 a6 80 f7 76 13 6f b5 12 61 35 9c a9 8a 68 47 75 69 e5 e6 3f e8 9d 52 67 ad ed d7 7e 9e 04 ab e2 29 7e 00 bd 27 a3 c0 7e ea 5d 13 8f bc 67 50 55 5e 82 1d 41 b4 a3 90 39 8a b4 9a 8d 60 ee 63 6b 3c 81 1d 07 6b c4 f1 31 6f 22 84 d2 ae f9 d6 55 46 1f 3c 75 7b 56 30 0a 0a 82 f7 22 3c 0d 77 1b dd ad 53 68 b7 de 5d fe 4c 5a 1f a3 33 fe b6 2f ff 3a 22 86 f2 21 ff 

The keyservers (pks, and apparently SKS) hash the pubkey packet exactly
as it appears.  Certain encryption clients deconstruct the packet,
normalize the MPIs, and hash the new components instead of the original
pubkey packet.  With a zero-padded MPI, which is non-RFC-compliant,
the non-RFC-compliant behavior of hashing something other than the
original pubkey packet breaks the fingerprint (and therefore keyid)
calculation, which causes further breakage.

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : /pipermail/attachments/20041214/93469b68/attachment.bin


More information about the Gnupg-users mailing list