sks-devel
[Top][All Lists]
Advanced

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

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


From: Yaron Minsky
Subject: [Sks-devel] Re: Debian SKS packages was: [pgp-keyserver-folk] new pgp key server
Date: Sun, 19 Sep 2004 10:11:32 -0400

Interesting.  I do remember discussing this before.  I'm not sure
offhand what the right solution is.  A few questions come to mind:

First, does anyone know what PKS does about this?  Does it have some
filter that tosses out packets with overlarge MPIs?  Or has the packet
in question simply not been submitted to the PKS network?

Second, why doesn't GPG just dump the packet in question?  Generally,
speaking, SKS doesn't look deeply into packets to make sure they're
good, and simply assumes that GPG and similar tools will toss out bad
packets.  This is really the principle that any non-cryptographic
keyserver must follow (including PKS).  So is there some principle
that makes it clear what kinds of problems GPG can filter out, and
what it can't?

Even if this is a properly understood as a GPG bug, fixing GPG might
not be to fix GPG, since SKS can be patched and updated more quickly,
potentially.

y


On Sat, 18 Sep 2004 12:58:19 +0200, Peter Palfrader <address@hidden> wrote:
> On Fri, 17 Sep 2004, Yaron Minsky wrote:
> 
> > On Fri, 17 Sep 2004 19:17:37 +0200, Peter Palfrader <address@hidden> wrote:
> > > On Fri, 17 Sep 2004, Anand Kumria wrote:
> > >
> > > > There is but afaik it hasn't been uploaded to the archive.
> > > >
> > > > I believe the debian-sks maintainers were awaiting some changes to ocaml
> > > > but I haven't been keeping with this issue lately.
> > >
> > > Last time I tried building my package it worked more or less.  However I
> > > have not uploaded it yet and don't think I will in the near future.  sks
> > > needs proper documentation first, and it should handle things like
> > > merging and taking dumps online (i.e. concurrent access to the db).
> > > Then there's some bug with sks serving and distributing broken keys,
> >
> > Your complaints mostly seem pretty accurate.  I'm not sure what you
> > mean by this one, though.  What's the bug with SKS serving and
> > distributing broken keys?  I don't know of any bugs where SKS mangles
> > keys.  It does, of course, distribute crypotgraphically broken keys,
> > but that is because, like PKS, SKS doesn't include any cryptography.
> > I don't consider that a bug.  So I'm curious as to what problem you're
> > referring to.
> 
> I mailed you about this several months ago:
> 
> address@hidden:~$ gpg --recv 04F130BC
> gpg: mpi too large (30918 bits)
> gpg: mpi too large (44843 bits)
> gpg: read_block: read error: invalid packet
> gpg: Total number processed: 0
> address@hidden:~$ gpg  --keyserver keyserver.kjsl.com  --recv 04F130BC
> gpg: key 04F130BC: public key "Ritesh Raj Sarraf (Ricky) <address@hidden>" 
> imported
> gpg: Total number processed: 1
> gpg:               imported: 1
> 
> This basically allows an attacker to make any key they want unuseable on
> the SKS network.  It may not be sks that mangled it, but it makes the
> key entirely unuseable.  There are several keys like this.
> 
> 
> 
> --
> Peter
> 
> _______________________________________________
> pgp-keyserver-folk mailing list
> address@hidden
> http://lists.alt.org/mailman/listinfo/pgp-keyserver-folk
>




reply via email to

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