Fuck it, serve the files directly.

author: Owen Jacobson <owen.jacobson@grimoire.ca> 2015-07-03 22:31:49 -0400
committer: Owen Jacobson <owen.jacobson@grimoire.ca> 2015-07-03 22:35:09 -0400
commit: 76aed6ef732de38d82245b3d674f70bab30221e5 (patch)
tree: d50e9a296d91ef8a49bcb29c3e80096f200a3c26 /.html/gpg/terrible.html
parent: 92f66d3e3a0996bb1fad9dc83d7e184f92673e5d (diff)
1 files changed, 198 insertions, 0 deletions
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 @@
+<!DOCTYPE html>
+<html>
+<head>
+	<title>
+		The Codex » 
+		GPG Is Terrible
+	</title>
+
+	<link
+		rel='stylesheet'
+		type='text/css'
+		href='http://fonts.googleapis.com/css?family=Buenard:400,700&amp;subset=latin,latin-ext'>
+	<link
+		rel="stylesheet"
+		type="text/css"
+		href="../media/css/reset.css">
+	<link
+		rel="stylesheet"
+		type="text/css"
+		href="../media/css/grimoire.css">
+</head>
+<body>
+
+<div id="shell">
+	
+		<ol id="breadcrumbs">
+			
+				<li class="crumb-0 not-last">
+					
+						<a href="../">index</a>
+					
+				</li>
+			
+				<li class="crumb-1 not-last">
+					
+						<a href="./">gpg</a>
+					
+				</li>
+			
+				<li class="crumb-2 last">
+					
+						terrible
+					
+				</li>
+			
+		</ol>
+	
+
+	
+	<div id="article">
+		<h1 id="gpg-is-terrible">GPG Is Terrible</h1>
+<p>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.</p>
+<p>S/MIME in the wild is a total non-starter. GPG, on the other hand, is merely
+really, <em>really</em> bad.</p>
+<p>(You may want to take this with a side of <a href="cool">the other perspective</a>.)</p>
+<h2 id="body-security-and-nothing-else">Body Security And Nothing Else</h2>
+<p>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.</p>
+<p>(Yes. Signed headers <em>would</em> mean that mailing lists can no longer inject
+<code>[listname]</code> 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.)</p>
+<p>In return for doing about half of its One Job, GPG demands a <em>lot</em> from its
+users.</p>
+<h2 id="the-real-name-policy">The Real Name Policy</h2>
+<p>The GPG community has a massive “legal names” fixation. <a href="http://cryptnet.net/fdp/crypto/keysigning_party/en/extra/signing_policy.html">Widespread GPG
+documentation</a>,
+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.</p>
+<p>As the <a href="http://www.jwz.org/blog/2011/08/nym-wars/">#nymwars</a> folks can tell
+you, this policy is harmful and limiting. There are good theoretical reasons
+to validate <em>an</em> identity before using its keys to secure messages, but legal
+identities can be anywhere from awkward to dangerous to use.</p>
+<p>GPG does not <em>technically</em> 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.</p>
+<p>As <a href="https://twitter.com/wlonk/">@wlonk</a> put it:</p>
+<blockquote>
+<p>I care about communicating with the coherent theory of mind behind @so-and-so.</p>
+</blockquote>
+<h2 id="issuing-identities">Issuing Identities</h2>
+<p>GPG makes issuing new identities simultaneously too easy and too hard for users.
+It's hard, because the <em>only</em> 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 <em>very</em> time-consuming to deploy a new name.</p>
+<h2 id="finding-paul-revere">Finding Paul Revere</h2>
+<p>It turns out autonymity in GPG would be pretty fragile even if GPG's user
+community <em>didn't</em> 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.</p>
+<p>A lot of people can be meaningfully identified by that information alone,
+even without publishing their personal identity.</p>
+<h2 id="the-web-of-vulnerable-cas">The Web Of Vulnerable CAs</h2>
+<p>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 <em>any</em> 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.</p>
+<p>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.</p>
+<h2 id="interoperability">Interoperability</h2>
+<p>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:</p>
+<ul>
+<li>In-band “cleartext” signing, which litters the email body with technical
+  noise, or</li>
+<li>PGP/MIME, which delivers a meaningless-looking “signature.asc” attachment.</li>
+</ul>
+<p>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.</p>
+<p>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.</p>
+<p>(Accidentally sending an <em>encrypted</em> email to a non-GPG-using recipient is,
+thankfully, hard enough to be irrelevant unless someone is actively spoofing
+their identity.)</p>
+<h2 id="webmail-need-not-apply">Webmail Need Not Apply</h2>
+<p>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!)</p>
+<p>Apparently Google's <a href="https://code.google.com/p/end-to-end/">finally fixing that for Chrome
+users</a>, so that's something.</p>
+<h2 id="mobile-need-not-apply">Mobile Need Not Apply</h2>
+<p><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!</del></p>
+<p>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 <a href="#comment-1422227740">his
+comment</a> for details.</p>
+<h2 id="further-reading">Further Reading</h2>
+<ul>
+<li><a href="http://secushare.org/PGP">Secushare.org's “15 reasons not to start using PGP”</a></li>
+<li><a href="https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html">Mike Perry's “Why the Web of Trust Sucks”</a></li>
+</ul>
+	</div>
+
+
+	
+<div id="comments">
+<div id="disqus_thread"></div>
+<script type="text/javascript">
+    /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
+    var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname
+
+    /* * * DON'T EDIT BELOW THIS LINE * * */
+    (function() {
+        var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
+        dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
+        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
+    })();
+</script>
+<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
+<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>
+</div>
+
+
+	
+	<div id="footer">
+		<p>
+			
+				The Codex —
+			
+			Powered by <a href="http://markdoc.org/">Markdoc</a>.
+			
+<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/gpg/terrible.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/gpg/terrible.md">history</a>).
+
+		</p>
+	</div>
+	
+</div>
+</body>
+</html>
+\ No newline at end of file
author	Owen Jacobson <owen.jacobson@grimoire.ca>	2015-07-03 22:31:49 -0400
committer	Owen Jacobson <owen.jacobson@grimoire.ca>	2015-07-03 22:35:09 -0400
commit	76aed6ef732de38d82245b3d674f70bab30221e5 (patch)
tree	d50e9a296d91ef8a49bcb29c3e80096f200a3c26 /.html/gpg/terrible.html
parent	92f66d3e3a0996bb1fad9dc83d7e184f92673e5d (diff)