diff options
Diffstat (limited to '.html/gpg/terrible.html')
| -rw-r--r-- | .html/gpg/terrible.html | 198 |
1 files changed, 0 insertions, 198 deletions
diff --git a/.html/gpg/terrible.html b/.html/gpg/terrible.html deleted file mode 100644 index 59f4afb..0000000 --- a/.html/gpg/terrible.html +++ /dev/null @@ -1,198 +0,0 @@ -<!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&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 |