On 07/20/2013 07:05 AM, micah wrote: > Hi Micah! Hey Micah!
> Micah Lee <micahf...@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 OpenPGP spec. 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 > http://sks-keyservers.net/overview-of-pools.php). 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[0] (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[1]. 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[1]. Hell, I can sign Snowden's key with my fake Nadim > Kobeissi key[1] 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, journalists, sources). 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![2] > > After all, we Micahs need to stick together, > micah > > 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. > -- Micah Lee @micahflee
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
