My people have no tradition of proofreading. —Ken White
This is the second of three posts on encrypting email. The others are It's Time to Encrypt Your Email and A Little About Encryption.
If you've followed the directions in "It's Time to Encrypt Your Email," you have an email client that's set up to encrypt messages you send and decrypt messages you receive. Now what?
Someone To Write To
Being the first person on your block to have public key cryptography for your email leaves you with no one with whom you can correspond securely. Let your frequent correspondents know about these articles and help them get started with public key cryptography for their email. If you recruit two people to use encryption and each of them also recruits two more, soon everyone will be doing what we should be doing.The Subject May Not Be Encrypted
If you're using Thunderbird version 78 or higher, the subject lines of your messages will be encrypted. Other encryption mechanisms may not encrypt the subject. This means that anyone who can eavesdrop on your mail stream can read your subject lines. If your main reason for encryption is to foil casual snooping, just use subject lines as usual, but be aware that you are potentially revealing information. Alternatively, you can use uninformative subjects like, "Encrypted message." (An eavesdropper will be able to tell which messages are encrypted anyway, so you haven't revealed anything.) For voluminous correspondence, where subject lines might be needed to categorize messages, and should not reveal information to eavesdroppers, you could use a code. A subject of, "Spending weekend with Grandpa" might indicate one type of message, and "What about pizza?" another.Or, you could use Thunderbird, which encrypts the subject line.
Traffic Analysis
An adversary who can eavesdrop on your email can see with whom you correspond even if the contents of the messages remain hidden. Sometimes inferences can be drawn from that information. For example, if the owner of a successful private company suddenly starts communicating with investment bankers, one could speculate that the company is about to go public. Traffic analysis countermeasures are far beyond the scope of this article, but users of encryption should be aware of the possibility that "they" know to whom you are writing, even though they can't read the messages.It is increasingly the case that email systems use TLS/SSL encryption between client and server, and from one email server to another. Although that makes traffic analysis more difficult, he header information of email messages is necessarily unencrypted while the message is "at rest," either on a server or at the origin or destination. An adversary with access to an email provider's servers can read all of the header information: sender, recipients, and the rest, and possibly subjects. Some adversaries, like governments, might be able to compel access to email providers' servers. Of course, if the adversary can install monitoring software on the computer at the origin or destination, no part of the message is secure, even if the body is encrypted.
Digital Certificates
If Evil Eve the Eavesdropper could somehow replace Alice's public key with Eve's own, then Eve would be able to read messages intended for Alice. We guard against that by embedding public keys in digital certificates. A self-signed digital certificate is a digest (electronic fingerprint) of the public key and identifying data, computed using a cryptographic hash function and encrypted with the owner's private key. Because public and private keys are cryptographic inverses of one another, anyone can compute the digest of Alice's digital certificate, then use Alice's public key (from the certificate) to decrypt the digest from the certificate, and finally compare the two. In theory, if the two digests match, one should be able to trust the public key. In practice, a self-signed digital certificate provides no significant protection against replacing both the public key and the encrypted fingerprint. Self-signing does protect the certificate from tampering.We overcome the problem that Eve could have generated a completely forged certificate by having the digital certificate signed with the private keys of one or more trusted third parties. One approach is to use a single trusted party, the certificate authority. The other approach, and the one employed by OpenPGP, is to have that key fingerprint signed by several third parties in whom we place varying degrees of trust. (Note: As of spring, 2021, the Hagrid keyserver at keys.openpgp.org does not support key signing.)
A third party signs a certificate by computing the digest of the identifier and public key, then encrypting it with the signer's private key. The signer's identity is added to the signature. Anyone can find the signer's public key and check the digital signature as described above.
There is more about digests in A Little About Encryption.
Key Signing
If a third party whom we trust has signed Alice's key, we can have a great deal of confidence that we really have Alice's key and not Eve's because changing the key would invalidate the signature. If we don't know the person who signed Alice's key, we have a lot less trust. Perhaps Eve has subverted the signer.If several people have signed Alice's key, our confidence increases because Eve the Eavesdropper would have had to subvert each of them. The more signers, the more confidence we can have, especially if one of the signers is known to us. This creates the "web of trust" that lets us have confidence that the public keys of others have not been tampered with, and does so without the need for a central authority.
You may be asked to "sign" someone's key, or you may want to ask someone to sign yours. To have a friend sign your key, approach the friend in person, with your name or email address and key fingerprint written on paper. If your friend agrees to sign your key,your friend will take the paper, obtain your public key from a key server, and verify that the key fingerprint you supplied on paper patches that of the key from the key server. If the two fingerprints match, your friend will get your key from a key server, "certify" the key as belonging to you by adding his digital signature, and send it back to the key server.
There's no need to go wild, but your key will be more trusted if at least four or five people have signed it; more is better. Try to have it signed by people who move in different circles; that will increase the probability the someone who needs your key will know someone who has signed it, or "know someone who knows someone."
A Key Signing Party
Since getting people who can verify each others' identity to sign each others' public keys is a Good Thing, and since socializing with like-minded people is also a Good Thing, you might want to host (or instigate) a key signing party. You won't even need access to computers at the party. The host prepares a list of attendees and information about their public keys and makes a copy for everyone at the party. Attendees bring their own key information and picture IDs to the party. Each guest checks the information for each other guest, and then later signs the keys of those whose information checks out. The "later" part is why you do not need, and should not have, computers at the party.There are many sets of instructions for organizing key signing parties on the web. The best one I've found so far is the W4KWH Key Signing Party Guide.
If you host or attend a key signing party, be sure you scrupulously verify the identification and key information of everyone whose key you intend to sign. Do not make this mistake:
Trusting Others' Certifications
Suppose Alice wants to communicate securely with Bob. She retrieves Bob's public key from a key server and finds that it has been signed by Charles, David, Frank, and George. Can we say more about how certain Alice can be that she really has Bob's public key than, "signed by four people?" Yes, especially if Alice knows any of those people, or knows anyone who has signed their keys..Alice (and you) can assign a level of trust to every key on her keyring of public keys. This is a subjective decision; Alice (and you) get to decide. The levels of trust are:
- Unknown
- Untrusted (known to sign public keys carelessly or maliciously; see the cartoon!)
- Marginally trusted (probably careful when signing public keys)
- Fully trusted.
Given the idea of levels of trust, one can apply an algorithm to help Alice decide whether the key she has retrieved from a key server for Bob is really his. A key is valid (i.e. trustworthy) if two conditions hold. First, it must have been signed by "enough" trusted keys. "Enough" means:
- Alice has signed it herself, or
- It has been signed with at least one key that is fully trusted by Alice, or
- It has been signed with at least three keys marginally trusted by Alice.
Those are the default parameters for GnuPG; you can change the parameters to be more or less restrictive. Levels of trust are private, and are not shared or exported when you sign someone else's public key.
Creating a Revocation Certificate
Once a key has been uploaded to a key server, it is effectively impossible to remove. Yet, you might want to remove your key for a number of reasons. It might be something as scary as having your private key compromised, or as mundane as getting a new email address, which is effectively a new identity. (You can also deal with a new email address using subkeys, which are explained in the Gnu Privacy Handbook. Subkeys are really the right way to deal with new addresses.) Although you can't remove a key from the key servers, you can revoke it... if you have a revocation certificate. Revoking your key tells everyone it is no longer effective to use that public key.The revocation certificate must be signed using your private key. One of the reasons you might want to revoke a public key is that you no longer have access to the corresponding private key. As I wrote in an earlier post, that can happen if you forget your passphrase or have a disk failure. So, generate that revocation certificate soon after you generate your key pair. Once you've generated a revocation certificate, do not import it. You will do that only if you're ready to revoke the public key. Instead, store it someplace safe. Remember, anyone who can get access to your revocation certificate can revoke your public key.
You will need to use the command interface of GnuPG to create your revocation certificate. Open a command window and navigate to the directory where gpg.exe is stored. On my computer, that's
\Program Files\GNU\GnuPG.
The command line to enter is
gpg --output <key ID>.revoke.asc --gen-revoke <key ID>
Where <key ID> represents the eight hex character ID of the key for which you want to create a revocation certificate. Here, edited slightly, is what it looked like when I created a revocation certificate for key ID 375F8696. What I typed is in bold.gpg --output 375f8696.revoke.asc --gen-revoke 375f8696 sec 2048R/375F8696 2013-04-07 Bob Brown <my_email> Create a revocation certificate for this key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 1 Enter an optional description; end with empty line: > Reason for revocation: Key has been compromised (No description given) Is this okay? (y/N) y You need a passphrase to unlock the secret key for user: "Bob Brown <my_email>" passphrase entered here 2048-bit RSA key, ID 375F8696, created 2013-04-07 ASCII armored output forced. Revocation certificate created.
The result will be a file called <key ID>.revoke.asc; in the example, 375F8696.revoke.asc, in the same directory where you ran the command. Do not leave it there! You need the revocation certificate if you lose access to your private key, which could happen if your computer is stolen or your hard disk fails.
These instructions came from the Gnu Privacy Handbook. I recommend having a good look at it to see what else one can do with
Signing Unencrypted Messages
Validating (Verifying) Signed Messages
Mail clients like Thunderbird can be configured to add digital signatures to all messages by default, even those that are not encrypted. Some can also be configured on a per-address basis. Consider adding a digital signature to all of your email, or at least to mail sent to friends who might be amenable to encrypting their own email.The cartoon is a little tongue-in-cheek... well, a lot tongue in cheek. Validation of signatures is automagic if the recipient is using an email client that understands OpenPGP. Such a client may even conceal the headers and just give a green bar or other indication that the message has been authenticated. Someone using an email client that doesn't understand OpenPGP can still validate digital signatures. To do so, copy the entire message, beginning with "-----BEGIN PGP SIGNED MESSAGE-----" and ending with "-----END PGP SIGNATURE-----" and save it to a temporary file. It can then be validated using the Decrypt/Verify File function of Kleopatra. (It's under the File menu.) The recipient must have imported the sender's public key certificate.
Thunderbird Portable Edition
My laptop goes where I go, so I can deal with encrypted email just about anywhere. If you primarily use a desktop computer and set up encryption there, it might be difficult to read or send encrypted email from elsewhere. One solution might be Thunderbird Portable Edition. This is Thunderbird bundled with the PortableApps launcher so that it will run from a USB flash drive. Using Thunderbird this way leaves no information behind on the host computer. The Windows operating system is required.If you set up and use Thunderbird Portable Edition, your private key will be on that flash drive; be sure to guard it well. Consider using an encrypted flash drive.
If you use any of the PortableApps applications, please consider making a donation or buying one of their flash drives. The software is free; the effort of making it portable is supported by donations.
Previous article: It's Time to Encrypt Your Email Next article:A Little About Encryption
Copyright © 2013 by Bob Brown
Last update: 2021-02-22
Last update: 2021-02-22
Using Encrypted Email by Bob Brown is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
The XKCD cartoons are used under the terms of the Creative Commons Attribution-NonCommercial 2.5 License.The quotation by Ken White is used by permission.
No comments:
Post a Comment