diff options
| author | Owen Jacobson <owen.jacobson@grimoire.ca> | 2014-06-06 20:22:12 -0400 |
|---|---|---|
| committer | Owen Jacobson <owen.jacobson@grimoire.ca> | 2014-06-06 20:22:12 -0400 |
| commit | d16bc487a03024bbdca3b9b788b57d959fed6e45 (patch) | |
| tree | 0f986b9cbed16371354eb34c291c39c262730996 | |
| parent | 5c27e3523938de37e2c078aebde0ea14a0cef64f (diff) | |
GPG also pretty neat, it turns out.
| -rw-r--r-- | wiki/gpg/cool.md | 67 | ||||
| -rw-r--r-- | wiki/gpg/terrible.md | 31 |
2 files changed, 86 insertions, 12 deletions
diff --git a/wiki/gpg/cool.md b/wiki/gpg/cool.md new file mode 100644 index 0000000..ae5962c --- /dev/null +++ b/wiki/gpg/cool.md @@ -0,0 +1,67 @@ +# GPG Is Pretty Cool + +The GPG software suite is a pretty elegant cryptosystem. It provides: + +* A standard, well-maintained set of tools for creating and storing keys, and + associating them with identities + +* A suite of reliable tools for encrypting, signing, decrypting, and + verifying data that can be easily assembled into any combination of + integrity checks, authenticity checks, and privacy management + +* A key distribution network that does not rely on hierarchal authority and + that can be bootstrapped from scratch quickly and easily + +While GPG [sucks in a number of important ways](terrible), it's also the best +tool we have right now for restoring privacy to private correspondance over +the internet. + +## Code Signing + +Pretty much every Linux distribution relies on GPG for code signing. Rather +than using GPG's web-of-trust model for key distribution, however, code +signing with GPG usually creates a hierarchal PKI so that the root keys can +be shipped with the operating system. + +This works shockingly well, and support for GPG is extremely well integrated +into common package management systems such as apt and yum. + +## Source Control + +Which is basically code signing, admittedly, but even Git's support for GPG +is basically great. Tools like Fossil embed it even deeper, and work quite +well. + +## Email + +GPG's integration with email is surprisingly clever, follows a number of +long-standing best practices for extending email, and does a _very_ good job +of providing some guarantees that make sense in a not-terribly-long-ago view +of email as a communications medium. In particular, if + +* who you talk to is not a secret, and +* what, broadly, you are talking about is not a secret, but +* the specifics of the discussion _are_ a secret, and +* all participants are using GPG on their own mailers + +then GPG works brilliantly and modern GPG integration is very effective. + +These assumptions pretty accurately reflect the majority of email use up +through the late 90s and early 2000s: technical or personal correspondence +between known acquaintences. + +The internet has moved on from email for casual correspondence, but that +doesn't invalidate the elegance of GPG's integration for GPG users. + +## Distributed Verification + +Even though GPG's trust model has some serious privacy costs and concerns, it +works as a great proof of concept for CA-free identity management. That's +huge: centralized CAs have even more onerous costs and worse risks than GPG's +trust network, while offering less transparency to help offset those costs. + +Others have written some pretty interesting things on how to improve GPG's +trust model and make it less succeptible to errors or key leaks by +small-to-middling numbers of participants. [This +post](https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html) +to tor-talk last year is probably the most complete. diff --git a/wiki/gpg/terrible.md b/wiki/gpg/terrible.md index 28edf23..46a65c4 100644 --- a/wiki/gpg/terrible.md +++ b/wiki/gpg/terrible.md @@ -9,13 +9,15 @@ incentives to screw you, or GPG. S/MIME in the wild is a total non-starter. GPG, on the other hand, is merely really, _really_ bad. +(You may want to take this with a side of [the other perspective](cool).) + ## Body Security And Nothing Else -GPG encrypts and signs email message bodies. That's it, that's all it does. -Email contains lots of other useful, potentially sensitive data: the subject -line, for example. GPG still exposes all of the headers for the world to see, -and conversely does nothing to detect or prevent header tampering by idiot -mailers. +GPG encrypts and signs email message bodies. That's it, that's all it does +when integrated with email. Email messages contain lots of other useful, +potentially sensitive data: the subject line, for example. GPG still exposes +all of the headers for the world to see, and conversely does nothing to +detect or prevent header tampering by idiot mailers. (Yes. Signed headers _would_ mean that mailing lists can no longer inject `[listname]` crud into your messages. Feature, not bug; we should be, and in @@ -39,14 +41,14 @@ you, this policy is harmful and limiting. There are good theoretical reasons to validate _an_ identity before using its keys to secure messages, but legal identities can be anywhere from awkward to dangerous to use. -GPG does not _technically_ restrict users from creating pseudonymous keys, -but the community at large discourages their use unless they can be traced -back to some legal identity. Pseudonymous keys tend to go unsigned by any -other key, cutting them off from the GPG trust network's validation effect. +GPG does not _technically_ restrict users from creating autonymous keys, but +the community at large discourages their use unless they can be traced back +to some legal identity. Autonyms keys tend to go unsigned by any other key, +cutting them off from the GPG trust network's validation effect. ## Finding Paul Revere -It turns out pseudonymity in GPG would be pretty fragile even if GPG's user +It turns out autonymity in GPG would be pretty fragile even if GPG's user community _didn't_ insist on puncturing it at every opportunity, since GPG irrevocably publishes the social graph of its users to every keyserver they use. You don't even have to publish it yourself; anyone who has a copy of @@ -99,6 +101,11 @@ users](https://code.google.com/p/end-to-end/), so that's something. ## Mobile Need Not Apply -Safely distributing GPG keys to mobile applications is more or less +<del>Safely distributing GPG keys to mobile applications is more or less impossible, and integration with mobile mail applications is nonexistant. -Hope you only ever read your mail from a Real Computer! +Hope you only ever read your mail from a Real Computer!</del> + +vollkorn points out that the above is inaccurate. He posted a couuple of +options for GPG on Android, and the state of the art for iOS GPG apps is +apparently better than I was able to find. See [his +comment](#comment-1422227740) for details. |
