Note: My Web pages are best viewed with style sheets enabled.
As explained elsewhere, using OpenPGP to exchange encrypted messages or files requires that others possess the user's public key and that the user possesses the public keys of others. Also explained elsewhere, using OpenPGP to verify someone's digital signature requires possession of the signer's public key. Finally, as explained elsewhere, you do not care who has your public key; you actually want your public key to be widely distributed.
The simplest way to distribute a public key is to upload it to a public key server. Be aware of the following when using a key server:
Another way to distribute a public key is to put it on a Web page of your own.
Distributing a public key via E-mail generally fails to make the key "widely distributed". If you nevertheless wish to distribute your public key via E-mail, it should not be embedded within the message. E-mail clients too often make subtle changes (e.g., line-breaks) in messages, changes that corrupt OpenPGP keys.
Some users generate their key-pairs with an expiration date; after that date, a new key-pair is needed because the old one is no longer valid. Other users decide to replace an existing key-pair when changing E-mail address, although a new address can easily be added to an existing key-pair. Then there is the situation when a key-pair must be revoked because it has been compromised, again requiring the generation of a new key-pair. An RSA v.3 key signed by a DH/DSS or RSA v.4 key will be treated as invalid by an OpenPGP application that handles only RSA v.3 keys (e.g., PGP v.2.6) and should be replaced.
Generating a new key-pair is simple. Just follow the user instructions for whatever OpenPGP application you are using. However, additional considerations apply beyond merely generating a new key-pair.
(Do not do this if the old key-pair was compromised and you know that it was already used improperly.)
Note that an expired or revoked key can still be used to verify a message or file signature made before key's expiration or revocation. However, an expired or revoked key cannot be used to verify another key.
If you don't want to wade through a lengthy, tedious description, just go to the summary at the end of this section.
US-CERT (United States Computer Emergency Readiness Team) is an agency of the U.S. Department of Homeland Security. Among other activities, US-CERT tracks and reports on computer vulnerabilities, such as viruses and susceptibility to hacking attacks. US-CERT failed to heed any of the points above, causing problems for users of its reports.
To allow verification of the authenticity of its reports on vulnerabilities (since many such reports are hoaxes written by others) and the integrity of those reports (since some hackers might want to alter the reports), US-CERT uses OpenPGP to digitally sign its reports. The signature is generated by US-CERT's Publications Key. To aid users in validating its various keys, US-CERT also has a Master Key-Signing Key, which is used to sign all other US-CERT keys — including the Publications Key. Having verified the authenticity of the Master Key-Signing Key, I signed it when I added it to my keyring.
On or about 16 September 2008, US-CERT released "Technical Cyber Security Alert TA08-260A". This report described a vulnerability affecting Apple computers, which my daughter uses. Before reading the report, I decided to verify the signature on it. The verification failed because the report was signed by a relatively new Publications Key that I did not have. I downloaded the new Publications Key from the US-CERT Web site; but I could not verify the new key it because it had been signed by the Master Key-Signing Key, which had expired.
*** Begin Right Sidebar ***Why did I call the US-CERT "hotline"? After all, the fingerprint on the Web page matched the fingerprint on the Master Key-Signing Key that I downloaded from a public key server.
The Web page was defective. The link to the Master Key-Signing Key was broken. That made me suspect the authenticity and integrity of the entire page, including the fingerprint documented there.
*** End Right Sidebar ***
A government agency involved in keeping the United States secure was very slipshod in maintaining its own infrastructure for the security of its Internet communications.
The following assumes that both the source and target computers are physically and electronically secure even if communication between them is not secure.
You have a computer at home and another one at work. You would like to use the same key-pair at both locations. How do you safely transfer the key-pair from the computer where it was generated to the other computer without compromising it? Different computer configurations require different methods.
The three methods below provide a secure process for transferring a key-pair. The first two involve the owner of the key-pair physically carrying removable media from the source computer to the target computer without allowing anyone else access to the media. The third involves encrypting the key-pair so that it may be sent over a non-secure communication channel (generally an electronic channel but also by another person carrying removable media).
Both computers are of the same type (e.g., both PCs or both Macs), and both have equivalent operating systems (e.g., both Windows). Both can use the same type of removable media (e.g., floppy disc, flash drive (memory stick)).
There are two simple ways to transfer:
When the transfer is completed, several issues must be addressed:
The computers are of a different type (e.g., one a PC and the other a Mac) or have different operating systems (e.g., one with Windows and the other with Linux). Both can use the same type of removable media.
The method is the same as in the second bullet under Two Similar Computers With Removable Media. However, when exporting the key-pair from the source computer, it must be done in ASCII format (the default for some OpenPGP applications). The first bullet under Two Similar Computers With Removable Media cannot be used because file formats might be different.
When the transfer is completed, the same issues must be addressed as under Two Similar Computers With Removable Media.
The computers might be of the same type with the equivalent operating systems, or they might not. Here the issue is that removable media cannot be used. There might not be any medium that is common and compatible between the two computers. One computer (or both) might have all capabilities for removable media disabled because of security concerns. One computer (or both) might not be physically accessible (accessible only via a remote terminal). Instead, communication between the two computers is over the Internet, an intranet, or a local-area network (LAN) none of which is secure.
The following sequence of steps will provide secure transfer of a key-pair from the source computer to the target computer through non-secure electronic communication:
(I actually used this method more than once where the two computers were dissimilar and where I could access one of them only through a remote terminal.)
When the transfer is completed, the issues to be addressed in this case are:
This third method may also be used with a removable medium if another person must be involved in carrying the medium between the two computers. In this case, to ensure that a bogus key-pair was not substituted for the actual key-pair, a test message should be signed on one computer and the signature verified on the other computer, both operations using the same key-pair.
29 October 2008
Updated 29 April 2010
Main PGP page
David Ross home
My PGP keys