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