| 1 | \define{versionidpgpkeys} \versionid $Id$ |
| 2 | |
| 3 | \A{pgpkeys} PuTTY download keys and signatures |
| 4 | |
| 5 | \cfg{winhelp-topic}{pgpfingerprints} |
| 6 | |
| 7 | \I{verifying new versions}We create \i{PGP signatures} for all the PuTTY |
| 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 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. |
| 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: |
| 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} |
| 46 | |
| 47 | \lcont{ |
| 48 | Master Key: 1024-bit; \I{PGP key fingerprint}fingerprint: |
| 49 | \cw{8F\_15\_97\_DA\_25\_30\_AB\_0D\_\_88\_D1\_92\_54\_11\_CF\_0C\_4C} |
| 50 | } |
| 51 | |
| 52 | \b DSA: |
| 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} |
| 56 | |
| 57 | \lcont{ |
| 58 | Master Key: 1024-bit; fingerprint: |
| 59 | \cw{313C\_3E76\_4B74\_C2C5\_F2AE\_\_83A8\_4F5E\_6DF5\_6A93\_B34E} |
| 60 | } |
| 61 | |
| 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. |