2285d016 |
1 | \define{versionidpgpkeys} \versionid $Id$ |
2 | |
3 | \A{pgpkeys} PuTTY download keys and signatures |
4 | |
5 | \cfg{winhelp-topic}{pgpfingerprints} |
6 | |
421406a4 |
7 | \I{verifying new versions}We create \i{PGP signatures} for all the PuTTY |
2285d016 |
8 | files distributed from our web site, so that users can be confident |
9 | that the files have not been tampered with. Here we identify |
10 | our public keys, and explain our signature policy so you can have an |
11 | accurate idea of what each signature guarantees. |
12 | This description is provided as both a web page on the PuTTY site, and |
13 | an appendix in the PuTTY manual. |
14 | |
15 | As of the next release, all of the PuTTY executables will contain |
16 | \#{XXX-REMOVE-BEFORE-RELEASE: fix this up for forthcoming release |
17 | As of release 0.58, all of the PuTTY executables contain} |
18 | fingerprint material (usually accessed via the \i\c{-pgpfp} |
19 | command-line option), such that if you have an executable you trust, |
20 | you can use it to establish a trust path, for instance to a newer |
21 | version downloaded from the Internet. |
22 | |
23 | (Note that none of the keys, signatures, etc mentioned here have |
24 | anything to do with keys used with SSH - they are purely for verifying |
25 | the origin of files distributed by the PuTTY team.) |
26 | |
27 | \H{pgpkeys-pubkey} Public keys |
28 | |
29 | We supply two complete sets of keys. We supply a set of RSA keys, |
30 | compatible with both \W{http://www.gnupg.org/}{GnuPG} and PGP2, |
31 | and also a set of DSA keys compatible with GnuPG. |
32 | |
33 | In each format, we have three keys: |
34 | |
35 | \b A Development Snapshots key, used to sign the nightly builds. |
36 | |
37 | \b A Releases key, used to sign actual releases. |
38 | |
39 | \b A Master Key. The Master Key is used to sign the other two keys, and |
40 | they sign it in return. |
41 | |
42 | Therefore, we have six public keys in total: |
43 | |
44 | \b RSA: |
82aaf5c3 |
45 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-rsa.asc}{Master Key}, |
46 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-rsa.asc}{Release key}, |
47 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-rsa.asc}{Snapshot key} |
2285d016 |
48 | |
49 | \lcont{ |
421406a4 |
50 | Master Key: 1024-bit; \I{PGP key fingerprint}fingerprint: |
2285d016 |
51 | \cw{8F\_15\_97\_DA\_25\_30\_AB\_0D\_\_88\_D1\_92\_54\_11\_CF\_0C\_4C} |
52 | } |
53 | |
2285d016 |
54 | \b DSA: |
82aaf5c3 |
55 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-dsa.asc}{Master Key}, |
56 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-dsa.asc}{Release key}, |
57 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-dsa.asc}{Snapshot key} |
2285d016 |
58 | |
59 | \lcont{ |
82aaf5c3 |
60 | Master Key: 1024-bit; fingerprint: |
2285d016 |
61 | \cw{313C\_3E76\_4B74\_C2C5\_F2AE\_\_83A8\_4F5E\_6DF5\_6A93\_B34E} |
62 | } |
63 | |
2285d016 |
64 | \H{pgpkeys-security} Security details |
65 | |
66 | The various keys have various different security levels. This |
67 | section explains what those security levels are, and how far you can |
68 | expect to trust each key. |
69 | |
70 | \S{pgpkeys-snapshot} The Development Snapshots keys |
71 | |
72 | These keys are stored \e{without passphrases}. This is |
73 | necessary, because the snapshots are generated every night without |
74 | human intervention, so nobody would be able to type a passphrase. |
75 | |
76 | The actual snapshots are built on a team member's home Windows box. |
77 | The keys themselves are stored on an independently run Unix box |
78 | (the same one that hosts our Subversion repository). After |
79 | being built, the binaries are uploaded to this Unix box and then |
80 | signed automatically. |
81 | |
82 | Therefore, a signature from one of the Development Snapshots keys |
83 | \e{DOES} protect you against: |
84 | |
85 | \b People tampering with the PuTTY binaries between the PuTTY web site |
86 | and you. |
87 | |
88 | But it \e{DOES NOT} protect you against: |
89 | |
90 | \b People tampering with the binaries before they are uploaded to the |
91 | independent Unix box. |
92 | |
93 | \b The sysadmin of the independent Unix box using his root privilege to |
94 | steal the private keys and abuse them, or tampering with the |
95 | binaries before they are signed. |
96 | |
97 | \b Somebody getting root on the Unix box. |
98 | |
99 | Of course, we don't believe any of those things is very likely. We |
100 | know our sysadmin personally and trust him (both to be competent and |
101 | to be non-malicious), and we take all reasonable precautions to |
102 | guard the build machine. But when you see a signature, you should |
103 | always be certain of precisely what it guarantees and precisely what |
104 | it does not. |
105 | |
106 | \S{pgpkeys-release} The Releases keys |
107 | |
108 | The Release keys have passphrases and we can be more careful about |
109 | how we use them. |
110 | |
111 | The Release keys are kept safe on the developers' own local |
112 | machines, and only used to sign releases that have been built by |
113 | hand. A signature from a Release key protects you from almost any |
114 | plausible attack. |
115 | |
116 | (Some of the developers' machines have cable modem connections and |
117 | might in theory be crackable, but of course the private keys are |
118 | still encrypted, so the crack would have to go unnoticed for long |
119 | enough to steal a passphrase.) |
120 | |
121 | \S{pgpkeys-master} The Master Keys |
122 | |
123 | The Master Keys sign almost nothing. Their purpose is to bind the |
124 | other keys together and certify that they are all owned by the same |
125 | people and part of the same integrated setup. The only signatures |
126 | produced by the Master Keys, \e{ever}, should be the signatures |
127 | on the other keys. |
128 | |
129 | We intend to arrange for the Master Keys to sign each other, to |
130 | certify that the DSA keys and RSA keys are part of the same setup. |
131 | We have not yet got round to this at the time of writing. |
132 | |
133 | We have collected a few third-party signatures on the Master Keys, |
134 | in order to increase the chances that you can find a suitable trust |
135 | path to them. We intend to collect more. (Note that the keys on the |
136 | keyservers appear to have also collected some signatures from people |
137 | who haven't performed any verification of the Master Keys.) |
138 | |
139 | We have uploaded our various keys to public keyservers, so that |
140 | even if you don't know any of the people who have signed our |
141 | keys, you can still be reasonably confident that an attacker would |
142 | find it hard to substitute fake keys on all the public keyservers at |
143 | once. |