Re: Key strangeness
Jason Harris <[email protected]> Tue, 14 Dec 2004 13:09:54 -0500
| Newsgroups | gmane.comp.encryption.pgp.sks,gmane.comp.gnu.gnupg.users,gmane.comp.encryption.pgp.keyserver-folk |
|---|---|
| Message-ID | <[email protected]> |
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? [email protected] _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004
signature.asc
(application/pgp-signature, 187 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBvyxxSypIl9OdoOMRAotFAJsH3Mg9UN5ypGs0hb0ltM7gMLQKWQCgzgd9 WUmSTmrjX9jEqXp+aqT2R/I= =lbor -----END PGP SIGNATURE-----