Previous | Contents | Index | Next
We create GPG 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 maintain multiple keys, stored with different levels of security due to being used in different ways. See section E.2 below for details.
The keys we provide are:
The current issue of those keys are available for download from the PuTTY website, and are also available on PGP keyservers using the key IDs listed below.
440D E3B5 B7A1 CA85 B3CC 1718 AB58 5DC6 0467 6F7C
0054 DDAA 8ADA 15D2 768A 6DE7 9DFE 2648 B434 34E4
2048R/C4FCAAD08A0AF00B). Encryption subkey ID:
8A26 250E 763F E359 75F3 118F C4FC AAD0 8A0A F00B
0A3B 0048 FE49 9B67 A234 FEB6 EEF2 0295 D15F 7E8A
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.
The Development Snapshots private key is stored without a passphrase. This is necessary, because the snapshots are generated every night without human intervention, so nobody would be able to type a passphrase.
The snapshots are built and signed on a team member's home computers, before being uploaded to the web server from which you download them.
Therefore, a signature from the Development Snapshots key DOES protect you against:
But it DOES NOT protect you against:
Of course, we take all reasonable precautions to guard the build machines. But when you see a signature, you should always be certain of precisely what it guarantees and precisely what it does not.
The Releases key is more secure: because it is only used at release time, to sign each release by hand, we can store it encrypted.
The Releases private key is kept encrypted on the developers' own local machines. So an attacker wanting to steal it would have to also steal the passphrase.
The Secure Contact Key is stored with a similar level of security to the Release Key: it is stored with a passphrase, and no automated script has access to it.
The Master Key signs almost nothing. Its 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 Key, ever, should be the signatures on the other keys.
The Master Key is especially long, and its private key and passphrase are stored with special care.
We have collected some third-party signatures on the Master Key, in order to increase the chances that you can find a suitable trust path to them.
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.
Our current keys were generated in September 2015, except for the Secure Contact Key which was generated in February 2016 (we didn't think of it until later).
Prior to that, we had a much older set of keys generated in 2000. For each of the key types above (other than the Secure Contact Key), we provided both an RSA key and a DSA key (because at the time we generated them, RSA was not in practice available to everyone, due to export restrictions).
The new Master Key is signed with both of the old ones, to show that it really is owned by the same people and not substituted by an attacker. Also, we have retrospectively signed the old Release Keys with the new Master Key, in case you're trying to verify the signatures on a release prior to the rollover and can find a chain of trust to those keys from any of the people who have signed our new Master Key.
Future releases will be signed with the up-to-date keys shown above. Releases prior to the rollover are signed with the old Release Keys.
For completeness, those old keys are given here:
8F 15 97 DA 25 30 AB 0D 88 D1 92 54 11 CF 0C 4C
313C 3E76 4B74 C2C5 F2AE 83A8 4F5E 6DF5 6A93 B34E
AE 65 D3 F7 85 D3 18 E0 3B 0C 9B 02 FF 3A 81 FE
00B1 1009 38E6 9800 6518 F0AB FECD 6F3F 08B0 A90B
86 8B 1F 79 9C F4 7F BD 8B 1B D7 8E C6 4E 4C 03
63DD 8EF8 32F5 D777 9FF0 2947 165E 56F7 7D3E 4A00
For Xming specific use see Xming-portablePuTTY.