Previous | Contents | Index | Next
We create PGP signatures for all the PuTTY files distributed from our web site, so that users can be confident that the files have not been tampered with. Here we identify our public keys, and explain our signature policy so you can have an accurate idea of what each signature guarantees. This description is provided as both a web page on the PuTTY site, and an appendix in the PuTTY manual.
As of release 0.58, all of the PuTTY executables contain fingerprint material (usually accessed via the
-pgpfp command-line option), such that if you have an executable you trust, you can use it to establish a trust path, for instance to a newer version downloaded from the Internet.
(Note that none of the keys, signatures, etc mentioned here have anything to do with keys used with SSH - they are purely for verifying the origin of files distributed by the PuTTY team.)
We supply two complete sets of keys. We supply a set of RSA keys, compatible with both GnuPG and PGP2, and also a set of DSA keys compatible with GnuPG.
In each format, we have three keys:
Therefore, we have six public keys in total:
Master Key: 1024-bit; fingerprint:
313C 3E76 4B74 C2C5 F2AE 83A8 4F5E 6DF5 6A93 B34E
The various keys have various different security levels. This section explains what those security levels are, and how far you can expect to trust each key.
These keys are stored without passphrases. This is necessary, because the snapshots are generated every night without human intervention, so nobody would be able to type a passphrase.
The actual snapshots are built on a team member's home Windows box. The keys themselves are stored on an independently run Unix box (the same one that hosts our Git repository). After being built, the binaries are uploaded to this Unix box and then signed automatically.
Therefore, a signature from one of the Development Snapshots keys DOES protect you against:
But it DOES NOT protect you against:
Of course, we don't believe any of those things is very likely. We know our sysadmin personally and trust him (both to be competent and to be non-malicious), and we take all reasonable precautions to guard the build machine. But when you see a signature, you should always be certain of precisely what it guarantees and precisely what it does not.
The Release keys have passphrases and we can be more careful about how we use them.
The Release keys are kept safe on the developers' own local machines, and only used to sign releases that have been built by hand. A signature from a Release key protects you from almost any plausible attack.
(Some of the developers' machines have cable modem connections and might in theory be crackable, but of course the private keys are still encrypted, so the crack would have to go unnoticed for long enough to steal a passphrase.)
The Master Keys sign almost nothing. Their purpose is to bind the other keys together and certify that they are all owned by the same people and part of the same integrated setup. The only signatures produced by the Master Keys, ever, should be the signatures on the other keys.
We intend to arrange for the Master Keys to sign each other, to certify that the DSA keys and RSA keys are part of the same setup. We have not yet got round to this at the time of writing.
We have collected a few third-party signatures on the Master Keys, in order to increase the chances that you can find a suitable trust path to them. We intend to collect more. (Note that the keys on the keyservers appear to have also collected some signatures from people who haven't performed any verification of the Master Keys.)
We have uploaded our various keys to public keyservers, so that even if you don't know any of the people who have signed our keys, you can still be reasonably confident that an attacker would find it hard to substitute fake keys on all the public keyservers at once.
If you want to provide feedback on this manual or on the PuTTY tools themselves, see the Feedback page.[PuTTY release 0.65]