Search Mailing List Archives
[liberationtech] Interesting things in keyservers
micahflee at riseup.net
Sun Jul 21 13:52:50 PDT 2013
On 07/20/2013 07:05 AM, micah wrote:
> Hi Micah!
> Micah Lee <micahflee at riseup.net> writes:
>> I'm working on a talk for OHM2013 about PGP. Can anyone send me examples
>> of interesting keys in key servers that you know of?
> Since you are preparing a talk about the subject, I'm going to be
> pedantic and correct your usage of "PGP", because it is important to get
> your terminology straight when giving a talk. I presume you aren't
> giving a talk about the commercial software, but instead you are
> actually giving a talk about OpenPGP which is the standard specified by
> RFC4880 that different programs like GnuPG, Seahorse, MacGPG, and PGP
> etc. all implement. If that is true, then you should refer to it as
> OpenPGP, and not PGP.
I've actually been trying to figure out the exact terminology to use.
The talk description uses GPG and GPG keys, however I think that's not
very accurate since GPG is just one piece of software that implement the
I also think that in general people use the terms PGP and OpenPGP
interchangeably (including the OpenPGP spec), even when the proprietary
software isn't part of the discussion. RFC4880 states that the headers
for ASCII armored OpenPGP data starts with:
BEGIN PGP MESSAGE
BEGIN PGP PUBLIC KEY BLOCK
BEGIN PGP PRIVATE KEY BLOCK
BEGIN PGP MESSAGE, PART X/Y
BEGIN PGP MESSAGE, PART X
BEGIN PGP SIGNATURE
The terminology is confusing, but I think I'll use OpenPGP over PGP most
of the time when it's appropriate.
> I dont know what your talk will consist of, besides the funny enigmail
> XSS and goatse.cx stuff (thanks for that! always good to have some
> goatse early in the morning), but I would like to point out a few things
> that might be useful to mention.
> One is a wiki page that I created with some people:
> https://we.riseup.net/riseuplabs+paow/openpgp-best-practices - it
> contains some useful hints about using OpenPGP, maintaining a good key
> and some general good practices that people often dont know about (such
> as the importance of keeping your keys updated to get critical
> revocation and expiration extension certifications!)
This is a great resource.
> One thing mentioned on that page that I wanted to highlight, because you
> used pgp.mit.edu links in your original email, is that the keyserver
> pgp.mit.edu is not a good one to use/promote. Everyone uses it as their
> 'goto' keyserver, but it is a really bad idea! As a keyserver, it has
> been broken for years. For a long time it was just dropping revocations,
> subkey updates and expirations on the floor. That is *really*
> bad. Eventually, they upgraded their keyserver software, but it is
> *still* running an older version of SKS, a version that fails to handle
> 16-digit subkeyid lookups (among other failings).
> So, please don't rely on pgp.mit.edu for your security, and please don't
> include them in your slides! If you are looking for one to use, I highly
> recommend using the SKS pool address (hkp://pool.sks-keyservers.net or
> http://hkps.pool.sks-keyservers.net/ - or if you want a more close
> geographical pool, have a look at
Interesting, I had no idea about MIT's key server. pgp.mit.edu is just
easy to remember, but I'll find a different key server to use for it's
web interface instead.
> Finally, there seems to be some amazing misconceptions about keyservers,
> keys and the web of trust. In particular this
> http://cryptome.org/2013/07/mining-pgp-keyservers.htm circulated
> recently and it pained me to see because it suggested various wreckless
> conclusions that were dangerously off the mark (and used pgp.mit.edu,
If you follow that link now, it includes this email you just wrote :).
I'm actually also planning on talking about this specific cryptome post.
> hah). While it is true that we've jokingly called the OpenPGP web of
> trust "the original social network" because of the exposed social
> relational graphing that can be done by querying keyservers, and it is
> for this reason that many activists I know do not want to have
> signatures uploaded to keyservers (and instead use the bulky local-only
> signature work-around)...
> ... but for some reason people seem to think that if it is on a
> keyserver, is true, or it means something that it doesn't. People don't
> realize critical things, such as the fact that I can create a key with
> the UID Nadim Kobeissi and upload it to the keyservers. That doesn't
> mean that is the real Nadim's key (this is what exchanging key
> fingerprints and doing certifications is for, so you can know, with a
> certain degree of certainty, that this person is the person who controls
> that secret key material).
> Or people think that because I signed your key and that signature is on
> the keyserver that indicates: I trust you; we met in person at that
> date; we know each other; we are involved in a criminal conspiracy with
> each other; or many other wrong assumptions about what that
> certification means. I can sign Edward Snowden's key and send that to
> the keyservers. Hell, I can sign Snowden's key with my fake Nadim
> Kobeissi key and then send it to the keyservers. Does that mean that
> Nadim and Snowden have met in person?! No, it does not at all.
Things like this--that you can't trust what's in the key server without
doing manual verification--are exactly what the talk is about. And of
course there's one-way trust vs two-way trust, the issue of compromised
keys that are well trusted, etc.
I also believe that OpenPGP (and the web of trust) is incredibly
byzantine for most people. It's really useful for package managers and
software developers and packagers. It's great for computer scientists
communicating privately with each other, and for other people who really
need it and are willing to climb over the learning curve (activists,
But there is so much to know and so many ways to make mistakes that I
think the cipherpunk future where everyone uses verified end-to-end
crypto won't actually be everyone using OpenPGP. The tools everyone will
use don't exist yet.
> Anyways, I can keep going... but I dont know what the focus of your OHM
> talk is about, so going on like this isn't particularly useful to you
> and your talk... however, I'd be happy to provide more feedback about
> your talk if you would like!
> After all, we Micahs need to stick together,
> 0. "the cryptome article just sounds like impenetrable bullshit from
> someone with no interest in actually understandning what's happening" -
> I'm not saying who said this...
> 1. no, I didn't do that, nor did I upload the edward snowden or bradly
> manning keys.
More information about the liberationtech