git.distorted.org.uk Git - u/mdw/putty/blob - doc/pgpkeys.but

   1 \define{versionidpgpkeys} \versionid $Id$
   2
   3 \A{pgpkeys} PuTTY download keys and signatures
   4
   5 \cfg{winhelp-topic}{pgpfingerprints}
   6
   7 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 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:
  45
  46 \lcont{
  47
  48 \b \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-rsa.asc}{Master Key}
  49
  50 \lcont{
  51 1024-bit; fingerprint:
  52 \cw{8F\_15\_97\_DA\_25\_30\_AB\_0D\_\_88\_D1\_92\_54\_11\_CF\_0C\_4C}
  53 }
  54
  55 \b \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-rsa.asc}{Release key}
  56
  57 \b \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-rsa.asc}{Snapshot key}
  58
  59 }
  60
  61 \b DSA:
  62
  63 \lcont{
  64
  65 \b \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-dsa.asc}{Master Key}
  66
  67 \lcont{
  68 1024-bit; fingerprint:
  69 \cw{313C\_3E76\_4B74\_C2C5\_F2AE\_\_83A8\_4F5E\_6DF5\_6A93\_B34E}
  70 }
  71
  72 \b \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-dsa.asc}{Release key}
  73
  74 \b \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-dsa.asc}{Snapshot key}
  75
  76 }
  77
  78 \H{pgpkeys-security} Security details
  79
  80 The various keys have various different security levels. This
  81 section explains what those security levels are, and how far you can
  82 expect to trust each key.
  83
  84 \S{pgpkeys-snapshot} The Development Snapshots keys
  85
  86 These keys are stored \e{without passphrases}. This is
  87 necessary, because the snapshots are generated every night without
  88 human intervention, so nobody would be able to type a passphrase.
  89
  90 The actual snapshots are built on a team member's home Windows box.
  91 The keys themselves are stored on an independently run Unix box
  92 (the same one that hosts our Subversion repository). After
  93 being built, the binaries are uploaded to this Unix box and then
  94 signed automatically.
  95
  96 Therefore, a signature from one of the Development Snapshots keys
  97 \e{DOES} protect you against:
  98
  99 \b People tampering with the PuTTY binaries between the PuTTY web site
 100 and you.
 101
 102 But it \e{DOES NOT} protect you against:
 103
 104 \b People tampering with the binaries before they are uploaded to the
 105 independent Unix box.
 106
 107 \b The sysadmin of the independent Unix box using his root privilege to
 108 steal the private keys and abuse them, or tampering with the
 109 binaries before they are signed.
 110
 111 \b Somebody getting root on the Unix box.
 112
 113 Of course, we don't believe any of those things is very likely. We
 114 know our sysadmin personally and trust him (both to be competent and
 115 to be non-malicious), and we take all reasonable precautions to
 116 guard the build machine. But when you see a signature, you should
 117 always be certain of precisely what it guarantees and precisely what
 118 it does not.
 119
 120 \S{pgpkeys-release} The Releases keys
 121
 122 The Release keys have passphrases and we can be more careful about
 123 how we use them.
 124
 125 The Release keys are kept safe on the developers' own local
 126 machines, and only used to sign releases that have been built by
 127 hand. A signature from a Release key protects you from almost any
 128 plausible attack.
 129
 130 (Some of the developers' machines have cable modem connections and
 131 might in theory be crackable, but of course the private keys are
 132 still encrypted, so the crack would have to go unnoticed for long
 133 enough to steal a passphrase.)
 134
 135 \S{pgpkeys-master} The Master Keys
 136
 137 The Master Keys sign almost nothing. Their purpose is to bind the
 138 other keys together and certify that they are all owned by the same
 139 people and part of the same integrated setup. The only signatures
 140 produced by the Master Keys, \e{ever}, should be the signatures
 141 on the other keys.
 142
 143 We intend to arrange for the Master Keys to sign each other, to
 144 certify that the DSA keys and RSA keys are part of the same setup.
 145 We have not yet got round to this at the time of writing.
 146
 147 We have collected a few third-party signatures on the Master Keys,
 148 in order to increase the chances that you can find a suitable trust
 149 path to them. We intend to collect more. (Note that the keys on the
 150 keyservers appear to have also collected some signatures from people
 151 who haven't performed any verification of the Master Keys.)
 152
 153 We have uploaded our various keys to public keyservers, so that
 154 even if you don't know any of the people who have signed our
 155 keys, you can still be reasonably confident that an attacker would
 156 find it hard to substitute fake keys on all the public keyservers at
 157 once.