tweak wording in "pscp -ls"
[u/mdw/putty] / doc / pgpkeys.but
CommitLineData
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 8files distributed from our web site, so that users can be confident
9that the files have not been tampered with. Here we identify
10our public keys, and explain our signature policy so you can have an
11accurate idea of what each signature guarantees.
12This description is provided as both a web page on the PuTTY site, and
13an appendix in the PuTTY manual.
14
15As of the next release, all of the PuTTY executables will contain
16\#{XXX-REMOVE-BEFORE-RELEASE: fix this up for forthcoming release
17As of release 0.58, all of the PuTTY executables contain}
18fingerprint material (usually accessed via the \i\c{-pgpfp}
19command-line option), such that if you have an executable you trust,
20you can use it to establish a trust path, for instance to a newer
21version downloaded from the Internet.
22
23(Note that none of the keys, signatures, etc mentioned here have
24anything to do with keys used with SSH - they are purely for verifying
25the origin of files distributed by the PuTTY team.)
26
27\H{pgpkeys-pubkey} Public keys
28
29We supply two complete sets of keys. We supply a set of RSA keys,
30compatible with both \W{http://www.gnupg.org/}{GnuPG} and PGP2,
31and also a set of DSA keys compatible with GnuPG.
32
33In 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
40they sign it in return.
41
42Therefore, 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 50Master 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 60Master 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
66The various keys have various different security levels. This
67section explains what those security levels are, and how far you can
68expect to trust each key.
69
70\S{pgpkeys-snapshot} The Development Snapshots keys
71
72These keys are stored \e{without passphrases}. This is
73necessary, because the snapshots are generated every night without
74human intervention, so nobody would be able to type a passphrase.
75
76The actual snapshots are built on a team member's home Windows box.
77The keys themselves are stored on an independently run Unix box
78(the same one that hosts our Subversion repository). After
79being built, the binaries are uploaded to this Unix box and then
80signed automatically.
81
82Therefore, 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
86and you.
87
88But it \e{DOES NOT} protect you against:
89
90\b People tampering with the binaries before they are uploaded to the
91independent Unix box.
92
93\b The sysadmin of the independent Unix box using his root privilege to
94steal the private keys and abuse them, or tampering with the
95binaries before they are signed.
96
97\b Somebody getting root on the Unix box.
98
99Of course, we don't believe any of those things is very likely. We
100know our sysadmin personally and trust him (both to be competent and
101to be non-malicious), and we take all reasonable precautions to
102guard the build machine. But when you see a signature, you should
103always be certain of precisely what it guarantees and precisely what
104it does not.
105
106\S{pgpkeys-release} The Releases keys
107
108The Release keys have passphrases and we can be more careful about
109how we use them.
110
111The Release keys are kept safe on the developers' own local
112machines, and only used to sign releases that have been built by
113hand. A signature from a Release key protects you from almost any
114plausible attack.
115
116(Some of the developers' machines have cable modem connections and
117might in theory be crackable, but of course the private keys are
118still encrypted, so the crack would have to go unnoticed for long
119enough to steal a passphrase.)
120
121\S{pgpkeys-master} The Master Keys
122
123The Master Keys sign almost nothing. Their purpose is to bind the
124other keys together and certify that they are all owned by the same
125people and part of the same integrated setup. The only signatures
126produced by the Master Keys, \e{ever}, should be the signatures
127on the other keys.
128
129We intend to arrange for the Master Keys to sign each other, to
130certify that the DSA keys and RSA keys are part of the same setup.
131We have not yet got round to this at the time of writing.
132
133We have collected a few third-party signatures on the Master Keys,
134in order to increase the chances that you can find a suitable trust
135path to them. We intend to collect more. (Note that the keys on the
136keyservers appear to have also collected some signatures from people
137who haven't performed any verification of the Master Keys.)
138
139We have uploaded our various keys to public keyservers, so that
140even if you don't know any of the people who have signed our
141keys, you can still be reasonably confident that an attacker would
142find it hard to substitute fake keys on all the public keyservers at
143once.