Re: [Sks-devel] Re: Debian SKS packages was: [pgp-keyserver-folk] new pgp key server

[David Shaw]

On Sun, Sep 19, 2004 at 02:42:34PM -0400, Yaron Minsky wrote:
> On Sun, 19 Sep 2004 11:33:55 -0400, David Shaw <address@hidden> wrote:
> > 
> > This particular one is hard to filter out since it is corrupt public
> > key data.  If the public key in question is the main public key then
> > the rest of the key is meaningless without it - filtering it is
> > effectively like filtering out the whole key (which is what happens).
> > 
> > In this particular case, the corrupt key is a public subkey, so it
> > could theoretically be filtered out and the key as a whole would just
> > be short one subkey.... but in practice this is difficult.  The packet
> > is corrupt, so we don't really know anything at this point.  In
> > particular, is the length of the packet itself sane?  If not, we can't
> > drop it since we don't know where the next packet starts.
> 
> Interesting.  This wouldn't be difficult from the way SKS handles
> things.  Basically, SKS first parses the key down to the packet level,
> which works without problems for this key.  Things like MPIs are only
> looked at within the packet level.  If one such is found to be bogus,
> the packet could then easily be thrown out.  I'm somewhat surprised
> it's not handled similarly in GPG.

But that's a problem also - you can't packetize something if the
packet boundaries are bogus.  Or rather you can, but you don't know
what you're going to get.

> Moreover, throwing out a corrupted packet and everything that depends
> on it seems like the only approach that is consistent with the SKS/PKS
> style of crypto-free keyservers.  If someone decides to add an extra
> bogus public subkey packet, the only thing that SKS can do in general
> is include it, since it can't detect most forms of bogosity.  And it
> seems like the only reasonable thing for GPG to do in this case is to
> drop it.

This particular form of bogosity is just syntax and can easily be
checked even without crypto.  It's a public key (or subkey, or
signature) with specified length X, that contains contents that add up
to more or less than X.  This can happen because MPIs have their own
length specified.  In a corruption case, the internal parts may not
add up to (or may add up to more than) the outer part.

For example, take the broken subpacket we've been talking about.  It
is an old-style #14 public subkey packet with the 3-octet header (2
octet length).  The length is 269 bytes.  We have the usual few bytes
of header, a version byte (4), 4 bytes for the creation date
(1061237196), 1 byte for algorithm (Elgamal encrypt-only).  That
leaves 263 bytes unaccounted for.  Next come the MPIs.  The first MPI
for Elgamal is the prime p.  The 2 length bytes say it is 1024 bits
long, so we read 128 bytes more.  That leaves 133 bytes of the
original packet unaccounted for.  The next MPI is the Elgamal
generator g.  The 2 length bytes say it is 30918 bits long, so we read
3865 bytes.... and bzzt!  We've walked off the end of the packet.
This packet is corrupt, and no crypto was needed to verify it.

The problem here is what, exactly, is corrupt?  Are one or more of the
MPIs broken... or is the original packet length wrong?  Either way,
the packet is shot, but in the first case it is possible to drop the
packet and keep going.  In the latter case, you have to stop since you
have no way of knowing where you are in the datastream any longer.

GnuPG, perhaps conservatively, kicks out the whole key import if it
detects this problem.  That a reasonable solution for a keyserver as
well.  It could theoretically try and accept the part of the key
before the corruption was detected, but it doesn't do that today.

I'm somewhat leery of the idea of a keyserver trying to do repair work
on corrupt keys.  I figure the key is busted.  Kick it back to the
submitter (or just drop it if learned from another server) and let the
original submitter fix it.

David

pgpF5lsxzbDRO.pgp
Description: PGP signature