Re: Debian SKS packages was: [pgp-keyserver-folk] new pgp key server
Yaron Minsky <[email protected]> Sun, 19 Sep 2004 10:11:32 -0400
| Newsgroups | gmane.comp.encryption.pgp.sks,gmane.comp.encryption.pgp.keyserver-folk |
|---|---|
| Message-ID | <[email protected]> |
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 <peter-YAb/UuZI+OFrovVCs/[email protected]> wrote: > On Fri, 17 Sep 2004, Yaron Minsky wrote: > > > On Fri, 17 Sep 2004 19:17:37 +0200, Peter Palfrader <peter-YAb/UuZI+OFrovVCs/[email protected]> 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: > > weasel@opium:~$ 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 > weasel@opium:~$ gpg --keyserver keyserver.kjsl.com --recv 04F130BC > gpg: key 04F130BC: public key "Ritesh Raj Sarraf (Ricky) <[email protected]>" 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 > [email protected] > http://lists.alt.org/mailman/listinfo/pgp-keyserver-folk >