sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] Re: Key strangeness


From: Jason Harris
Subject: [Sks-devel] Re: Key strangeness
Date: Tue, 14 Dec 2004 13:09:54 -0500
User-agent: Mutt/1.4.2.1i

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?
address@hidden _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

Attachment: pgplFI4VNz1kb.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]