Date: Fri, 3 Jul 2015 22:31:49 -0400 Subject: Fuck it, serve the files directly. --- .html/gpg/_list.html | 92 ++++++++++++++++ .html/gpg/cool.html | 146 ++++++++++++++++++++++++++ .html/gpg/index.html | 92 ++++++++++++++++ .html/gpg/keys.html | 271 ++++++++++++++++++++++++++++++++++++++++++++++++ .html/gpg/terrible.html | 198 +++++++++++++++++++++++++++++++++++ 5 files changed, 799 insertions(+) create mode 100644 .html/gpg/_list.html create mode 100644 .html/gpg/cool.html create mode 100644 .html/gpg/index.html create mode 100644 .html/gpg/keys.html create mode 100644 .html/gpg/terrible.html (limited to '.html/gpg') diff --git a/.html/gpg/_list.html b/.html/gpg/_list.html new file mode 100644 index 0000000..8f54701 --- /dev/null +++ b/.html/gpg/_list.html @@ -0,0 +1,92 @@ + + + + + The Codex » + ls /gpg + + + + + + + + +

+ +

+ + index + +
+ + gpg + +
+ + list + +

+ + + +

`ls /gpg`

+ + + + +

Pages

+ + + +

+ + + + + + + + +

+ + \ No newline at end of file diff --git a/.html/gpg/cool.html b/.html/gpg/cool.html new file mode 100644 index 0000000..528ce0c --- /dev/null +++ b/.html/gpg/cool.html @@ -0,0 +1,146 @@ + + + + + The Codex » + GPG Is Pretty Cool + + + + + + + + +

+ +

+ + index + +
+ + gpg + +
+ + cool + +

+ + + +

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, 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 +to tor-talk last year is probably the most complete.

+ + + +

+ + +comments powered by Disqus +

+ + + + + +

+ + \ No newline at end of file diff --git a/.html/gpg/index.html b/.html/gpg/index.html new file mode 100644 index 0000000..8f54701 --- /dev/null +++ b/.html/gpg/index.html @@ -0,0 +1,92 @@ + + + + + The Codex » + ls /gpg + + + + + + + + +

+ +

+ + index + +
+ + gpg + +
+ + list + +

+ + + +

`ls /gpg`

+ + + + +

Pages

+ + + +

+ + + + + + + + +

+ + \ No newline at end of file diff --git a/.html/gpg/keys.html b/.html/gpg/keys.html new file mode 100644 index 0000000..9fe112b --- /dev/null +++ b/.html/gpg/keys.html @@ -0,0 +1,271 @@ + + + + + The Codex » + GPG Keys + + + + + + + + +

+ +

+ + index + +
+ + gpg + +
+ + keys + +

+ + + +

GPG Keys

If you've read GPG Is Terrible and GPG Is Pretty Cool, +and their references, and for some reason still feel the need to use GPG, my +key fingerprint is 77BD C4F1 6EFD 607E 85AA B639 5023 2991 F10D FFD0. The +key itself is below.

+ + + +

+ + +comments powered by Disqus +

+ + + + + +

+ + \ No newline at end of file diff --git a/.html/gpg/terrible.html b/.html/gpg/terrible.html new file mode 100644 index 0000000..59f4afb --- /dev/null +++ b/.html/gpg/terrible.html @@ -0,0 +1,198 @@ + + + + + The Codex » + GPG Is Terrible + + + + + + + + +

+ +

+ + index + +
+ + gpg + +
+ + terrible + +

+ + + +

GPG Is Terrible

A discussion at work reminded me that I hadn't looked at the state of the art +for email and communications security in a while. Turns out the options +haven't changed much: S/MIME, which relies on x.509 PKI and is therefore +unusable unless you want to pay for a certificate from someone with lots of +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.)

Body Security And Nothing Else

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 +many cases already are, storing that in a header of its own, not littering +the subject line. We also need to keep improving mail tooling, to better +handle those headers.)

In return for doing about half of its One Job, GPG demands a lot from its +users.

The Real Name Policy

The GPG community has a massive “legal names” fixation. Widespread GPG +documentation, +and years of community inertia, stand behind expecting people to put their +legal name in their GPG key, and conversely expecting people to verify the +identity in a GPG key (generally by checking government ID) before signing it.

As the #nymwars folks can tell +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 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.

As @wlonk put it:

+
I care about communicating with the coherent theory of mind behind @so-and-so.
+

Issuing Identities

GPG makes issuing new identities simultaneously too easy and too hard for users. +It's hard, because the only way to issue a new identity on an existing key +(and thus associated with and able to share correspondence with an existing +identity) requires that the user have access to their personal root key. There's +no way to create ad-hoc identities and bind them after the fact, making it hard +to implement opportunistic tools. (OTR's on-demand key generation fails to the +opposite extreme.) It's easy, because there's no mechanism beyond the web of +trust itself to vet newly-created keys or identities; the GPG community +compounds this by demanding that everyone carefully vet legal identities, making +it very time-consuming to deploy a new name.

Finding Paul Revere

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 +your public key can upload a copy for you, revealing to the world the +identities of everyone who knows you well enough to sign your key, and when +they signed it.

A lot of people can be meaningfully identified by that information alone, +even without publishing their personal identity.

The Web Of Vulnerable CAs

Each GPG user is also a unilateral signing authority. GPG's trust model means +that a compromised key can be used to confer validity onto any other key, +compromising potentially many other users by causing them to trust +illegitimate keys. GPG assumes everyone will be constantly on watch for +unusual signing activity, and perfectly aware of the safety of their own keys +at all times.

Given that the GPG signature graph is largely public, it should be possible to +moderate signatures using clique analysis, limiting the impact of a trusted +party who signs inauthentic identities. Unfortunately, GPG makes it challenging +to implement this by providing almost no support for iteratively deepening the +local keyring by downloading signers' keys as needed.

Interoperability

Sending a GPG-signed message to a non-GPG-using normal human being is a great +way to confuse the hell out of them. You have two options:

In-band “cleartext” signing, which litters the email body with technical + noise, or
PGP/MIME, which delivers a meaningless-looking “signature.asc” attachment.

In both cases, the recipient is left with a bunch of information they (a) +can't use and (b) can't hide or remove. It might as well say “virus.dat” for +all the meaning it conveys.

Some of this is not GPG's fault, exactly, but after over a decade, surely +either advocacy or compromise with major mail vendors should have been +possible.

(Accidentally sending an encrypted email to a non-GPG-using recipient is, +thankfully, hard enough to be irrelevant unless someone is actively spoofing +their identity.)

Webmail Need Not Apply

Well, unless you want to write the message text in an editor, copy and paste +it into GPG, and copy and paste the encrypted blob back out into your +message. (Hope your webmail's online editor doesn't mangle dashes or quotes +for you!)

Apparently Google's finally fixing that for Chrome +users, so that's something.

Mobile Need Not Apply

~~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!~~

vollkorn points out that the above is inaccurate. He posted a couple 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 for details.

ls /gpg

Pages

GPG Is Pretty Cool

Code Signing

Source Control

Email

Distributed Verification

ls /gpg

Pages

GPG Keys

GPG Is Terrible

Body Security And Nothing Else

The Real Name Policy

Issuing Identities

Finding Paul Revere

The Web Of Vulnerable CAs

Interoperability

Webmail Need Not Apply

Mobile Need Not Apply

Further Reading

`ls /gpg`

`ls /gpg`