looking up pgp keys

Robert J. Hansen rjh at sixdemonbag.org
Fri Sep 13 01:00:56 CEST 2013

On 9/12/2013 10:10 AM, Hauke Laging wrote:
> The answer is above. An unreliable system is inacceptable from legal 
> perspective.

Your definition of 'unreliable' is interesting.

The keyservers make *absolutely no assurances* about the certificate
they're giving you.  It's just a bunch of bits.  The certificate itself
is what gives confidence and reliability.

If we were to add strong crypto to the keyserver network, the size of
the SKS codebase would explode -- and with it, the bug count.  Complex
systems are fragile systems.  Compare how many security-critical bugs
there have been in GnuPG versus how many there have been in SKS.  (This
is not a slam against GnuPG!  I'm just pointing out the vast difference
in code base size, and the impact it has on reliability.)

If we were to do what you believe is necessary to make keyservers
"reliable", it would have the effect of making them vastly more unreliable.

John Clizbe, whom I believe is one of the maintainers for SKS, can often
be found on this list.  I'd love to hear his thoughts on whether adding
these reliability features to SKS would enhance or diminish SKS's security.

> But the public must be capable of proving that he didn't.

Can't be done, bang, period, end of sentence.  Some people like to think
OpenPGP provides nonrepudiability, but that's an ephemera.  If you don't
control your PC -- if you're playing host to malware -- it's very easy
to say, "but I didn't write that!" and have it be completely credible.

I have seen PGP-signed spam mail.  The victim had PGP set up as an
outbound mail proxy to sign everything, and the victim got hit by
malware and turned into a spambot.

In an era where about one desktop in three is compromised, you cannot
rely on cryptographic protocols to provide nonrepudiability.

> It's enough that the keyserver does the signing.

Well, that's a disaster right there.  Now on top of hundreds of
keyservers we've got each one of them serving as its own timestamp
authority.  What happens when two of them conflict?  What happens when
one gets the latest time zone update file and another doesn't?  What
happens then one corrects for a leap second and another doesn't?  And
how do they all stay in sync, anyway?

More information about the Gnupg-devel mailing list