-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
129 lines (105 loc) · 8.27 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0" />
<title>Evil 32: Check Your GPG Fingerprints</title>
<link rel="stylesheet" href="//fonts.googleapis.com/css?family=Lato:300,400,400italic" type="text/css">
<link rel="stylesheet" href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css" type='text/css'>
<link rel="stylesheet" href="/evil32.css" type='text/css'>
<link rel="icon" type="image/png" href="/favicon.png" />
<!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="//oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="//oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
</head>
<body>
<div class="container">
<h1>Evil 32: Check Your GPG Fingerprints</h1>
<div class="row">
<div class="col-lg-4 col-md-4 col-sm-4 col-lg-push-8 col-md-push-8 col-sm-push-8" style="padding-top: 30px; text-align: center;"></div>
<div class="col-lg-8 col-md-8 col-sm-8 col-lg-pull-4 col-md-pull-4 col-sm-pull-4">
GPG usage has grown steadily while the tooling that supports it remains stagnant despite staggering hardware advancement. 32bit key ids were reasonable 15 years ago but are obsolete now. Using modern GPUs, we have found collisions for every 32bit key id in the WOT's (Web of Trust) strong set. Although this does not break GPG's encryption, it further erodes the usability of GPG and increases the chance of human error.
</div>
</div>
<div class="row">
<div class="col-lg-6 col-md-6 col-sm-6">
<h3>Stop using 32bit key ids</h3>
<p>It takes 4 seconds to generate a colliding 32bit key id on a GPU (using <a target="_blank" href="https://github.com/lachesis/scallion">scallion</a>). Key servers do little verification of uploaded keys and allow keys with colliding 32bit ids. Further, GPG uses 32bit key ids throughout its interface and does not warn you when an operation might apply to multiple keys.</p>
</div>
<div class="col-lg-6 col-md-6 col-sm-6">
<h3 class="obsolete">Check your fingerprints</h3>
<p class="obsolete">Key servers do not use transport encryption (e.g. SSL) and GPG does not verify keys received when using <code>--recv-keys</code> leaving communicaiton with key servers vulnerable to MITM (man in the middle) or DNS attacks. GPG assumes you have manually checked your keys with <code>--fingerprint</code>.
</p>
<p><b><a href="http://bugs.gnupg.org/gnupg/issue1579" target="_blank">Patched in new versions of GPG!</a></b></p>
</div>
</div>
<div class="row">
<div class="col-lg-12 col-md-12 col-sm-12">
<h3>Examples</h3>
<a name="duplicate-recv-key-example"></a><h4>32bit key ids are not secure</h4>
<p>In the example below, a key is requested with its 32bit key id. The key server has two keys with the specified key id and GPG imports both keys. It is easy to generate and publish a key that looks identical if you only use 32 bits when specifying a key.</p>
<pre>
<b>free@turing ~$</b> gpg --keyserver pgp.mit.edu --recv-keys 10000001
<b>gpg:</b> requesting key 10000001 from hkp server pgp.mit.edu
<b>gpg:</b> key 10000001: public key "John Doe" imported
<b>gpg:</b> key 10000001: public key "Jane Doe" imported
<b>gpg:</b> Total number processed: 2
<b>gpg:</b> imported: 2 (RSA: 2)
</pre>
<h4 class="obsolete">GPG does not verify received keys</h4>
<p class="obsolete">GPG simply imports whatever the key server sends. No verfication of the response is done before importing.
<i>GPG assumes users will manually verify keys received with <code>--recv-keys</code></i>. In the example below, a key is requested and GPG blindly imports a different key.</p>
<pre class="obsolete">
<b>free@turing ~$</b> gpg --keyserver pgp.mit.edu --recv-keys 10000001
<b>gpg:</b> requesting key 10000001 from hkp server pgp.mit.edu
<b>gpg:</b> key 0BADBEEF: public key "Evil32" imported
<b>gpg:</b> Total number processed: 1
<b>gpg:</b> imported: 1 (RSA: 1)
</pre>
<h4><a href="/examples.html">In-depth real world example</a></h4>
<h3>Q&A</h3>
<h4>Where is the source code for the tool you used to duplicate the strong set?</h4>
<p>The tool is called Scallion and the source can be found at <a href="https://github.com/lachesis/scallion" target="_blank">https://github.com/lachesis/scallion</a>.</p>
<h4>Is your clone of the strong set publicly available?</h4>
<p>Yes. You can <a href="https://raw.githubusercontent.com/thingless/evil32/gh-pages/cloneset.tar.gz">download</a> an 89MiB tar.gz file which contains all generated keys.</p>
<a name="revoked"></a>
<h4>I saw that your clone of the strong set is revoked?</h4>
<p>Someone downloaded our copy of the strong set and uploaded all of the keys to the SKS keyserver network. :( While we took on this project to help prompt GPG to build a more secure ecosystem, this mass clone made the keyservers harder for everyone to use. Of course anyone could use our tools to regenerate their own strong set clone and do this again, but we'd rather our keys not be used that way.</p>
<h4>How could GPG be fixed?</h4>
<p>Key exchange is hard and there are no perfect solutions. That being said, there are some changes that could be made to GPG to make things better.</p>
<ul>
<li>When it's ambiguous what key an operation should act on (because of key id collisions or uuid collisions) GPG should refuse to perform the operation automatically. This would fix the issue of <a href="#duplicate-recv-key-example">receiving keys</a>.</li>
<li class="obsolete">If you specify a key id or fingerprint when using <code>--recv-keys</code> GPG should verify that the key/keys returned by the key server actually have the key id or fingerprint you requested.</li>
</ul>
<h4>Aren't you suppose to use the Web of Trust to verify the authenticity of keys?</h4>
<p>Absolutely! The web of trust is a great mechanism by which to verify keys but it's complicated. As a result, it is often not used. There are examples of GPG being used without the Web of Trust all over the web.</p>
<blockquote>The Warning: "no ultimately trusted keys found" means that gpg was not configured to ultimately trust a specific key. Trust settings are part of OpenPGPs Web-of-Trust which does not apply here. - <a href="https://wiki.debian.org/SecureApt" target="_blank"/>Debian SecureApt Wiki</a></blockquote>
<h4>I know about the problems with 32bit key ids, am I safe now?</h4>
<p>That depends. Many tools use GPG behind-the-scenes and have the same problems, but never directly show you fingerprints or prompt you. Check that maintainers of software you use are aware of these problems as well.</p>
<h4>Who should I contact with questions?</h4>
<p>If you have questions related to this page or <a href="https://github.com/lachesis/scallion" target="_blank">scallion</a> you should email <a href="mailto:[email protected]?Subject=Evil32">[email protected]</a></p>
<h4>Who authored this page?</h4>
<p>
<u>Richard Klafter</u><br>
Email: <img src="/richard_email.png"><br>
GPG fingerprint: <code>CB7C8A7B567FB2C2ACC2873B04FAC2E9CC21424A</code><br>
GPG key: <a href="/RichardKlafter.gpg" download>download here</a><br>
<u>Eric Swanson</u><br>
Email: <img src="/eric_email.png"><br>
GPG fingerprint: <code>9E15397E4D537E3A3A238F87E620C8A74BAF5D09</code><br>
GPG key: <a href="/EricSwanson.gpg" download>download here</a><br>
</p>
<p><small>
<a href="http://triciaroxane.wordpress.com/2014/08/06/sometimes-ferocious-is-adorable/">
Evil32 logo is free to use under the Creative Commons Attribution 3.0 License.</a>
</small></p>
<p class="timestamp">Page posted 2014-07-03 15:49 UTC.</p>
<p class="timestamp">Updated to reflect GPG patch 2014-12-01 02:01 UTC.</p>
</div>
</div>
</div>
</body>
</html>