Two-way PGP email without publishing your key / address to a key server?

Question

If I want to have some privacy and avoid the attention of publishing my email address to the public key server web of trust, yet have a secure two-way email conversation with one recipient, what are the ways in which we can share public keys, in order to have the secure conversation?

I am concerned about:

• My email being publically associated with PGP. (It is a privacy issue)
• My email having spam sent to it as a result of being on the public lists.
• The very existence of my email address being easily findable by anyone other than the people I want to communicate with.

I can so far think of ways such as exchanging keys over a trusted, secure OTR IM conversation, or physically/in person, but if you trust your respective email hosts / a third party not to change the keys with a MITM attack, could simply exchanging your keys via unencrypted email be a workable solution for what I want to (or rather, not want to) do?

And do many privacy-conscious people (like members of law enforcement, such as NSA agents) do this to avoid having their (government) email addresses publically 'outed' by being on public PGP key lists? Maybe they have their own private PGP servers within each organication to take care of that?

Answer 1

Confidential Key Transmission

You have to discriminate between to different issues:

1. Privately transmitting keys

   This is your primary challenge, about how to get the key to the other side without revealing it to the public. You can do this on any way you want which you would also trust otherwise regarding transmitting confidential data. If OTR is fine for you, than it also is for transmitting your keys.

   Sending keys without using key servers is as easy as

   gpg --armor --export [key-id] > key.asc     # Send file key.asc to the recipient
   gpg --import key.asc                        # Recipient can import the key
   

2. Verifying the validity of keys

   This is a completely disconnected problem, which also occurs if not transmitting key data in private (ie., using the key servers). Usually, this is performed by communicating the key's fingerprint (a kind of hash sum) over some secure channel, often face to face communication.

If you already established a trusted, secure channel (like OTR with verified keys), you could use this to do both: you know nobody is able to evesdrop, and the other side is authenticated.

If you trust your mail and network operators not to tamper with unsigned plain text mails (and not evesdrop on them), and governmental agencies are not an attack vector you're caring about, a plain text mail might be fine for doing so. If all you want to do is prevent spammers from getting your key (which includes your mail address), this is very likely sufficiently private way of exchanging keys, just consider who might have access to the transmission path: spammers are probably not among them.

Is it worth the effort?

Or better: how much effort is it worth?

Be aware that anybody being man in the middle will be able to observe whom you're communicating with anyway. Spam is an issue with keys on public key servers, but you have to deal with it anyway. Keeping keys private only works as long nobody makes a mistake; uploading the wrong or even all keys in the local key store is told to happen (and happens easily).

OpenPGP with its key server infrastructure is mainly designed to keep the contents of your communication private, while also ensuring authenticity by sharing your public keys and signatures. While it can be used the way you'd like it to be, keep in mind this is not one of the primary goals. If you want to use OpenPGP without uploading the keys, expect it to get public anyway and do not rely on it if a leaking public key would be a disaster.

Governmental Encrypted Mail Usage

And do many privacy-conscious people (like members of law enforcement, such as NSA agents) do this to avoid having their (government) email addresses publically 'outed' by being on public PGP key lists? Maybe they have their own private PGP servers within each organication to take care of that?

Very likely, they just don't use OpenPGP. These are centrally organized organizations, which are often better of using hierarchical systems like X.509. And worse, I'd not be too sure usage of end-to-end encrypted messages is widely spread anyway.

If they do, they will most likely use S/MIME and X.509 keys together with an internal key server being integrated in their user database. Very likely there is no full list of keys/certificates available; but when they're already communicating with you, they will very likely share the certificate by signing their mails (in S/MIME, the certificate containing the public key is attached to any signed message).

Answer 2

You don’t have to include your email address.

A user ID typically consists of a name, a comment (often omitted), and an email address, but this is not required by the OpenPGP specification.

Note that tools for creating OpenPGP keys may require entering the user ID in some specific way, though. GnuPG 1.4, for example, requires a name with more than 4 characters (which can’t start with a number), but comment and email address are optional.

Contra

Not specifying an email address has three possible drawbacks:

• {a} Some communication partners might get confused when managing your key. (Huh, why is the email address missing? Whose key was that again? To which of the three John Does I know does this key belong?)

• {b} If email client key managers automatically associate/preselect keys when composing an email to a new recipient, this would obviously fail. (Damn, I have to select the key manually!)

• {c} Some Web of Trust participants might not want to sign your key if it misses an email address.

In your scenario, probably none of these matter:

• About {a}: Your communication partner likely understands this and will know whose key it is (in addition, you could use a (nick)name which only your partner knows/understands).

• About {b}: Your communication partner would have to associate your key with your email address in the mail client only the first time, after which the client typically remembers this.

• About {c}: You don’t want to participate in the Web of Trust with this key (and even if, without your email adress anyway).

Pro

• {A} You could even use public key servers if the email address is your only concern.

• {B} If your key gets published to a key server somehow, your email address doesn’t/can’t leak.

I think these are even pros in your scenario:

• about {A}: You could use key servers which makes life easier for you and your communication partner if you change/update subkeys. You’d just use the key ID for finding the key.

• about {B}: Some tools might make publishing keys too easy, so your communication partner could accidentally publish it some day.

---

Verifying that you have the correct key works exactly the same way as if you’d include your email address: You have to communicate with your partner over a secure channel for one time (only) and compare the fingerprints.

Answer 3

Yes, sending the key in the first (plaintext) email would work.

This is essentially what most people do when they blindly accept a new ssh host key.

Even if you are not going to verify the other side identity -like you should-, before sending mildly confidential data, the bets are still good for you:

• Perhaps you are not being spied every time. Your email could pass through.
• If at one point you start being spied, past exchanges would be safe.
• They might not have the program available/enabled to MITM all your key exchanges.
• They don't know if you are going to immediately phone your recipient to confirm the fingerprint.
• Two-way messages need to be altered for an indefinite time.
• You could verify your partner identity weeks/months later.
• There is a limited timeframe to MITM your exchange (compare with reading an email archive).

Unlike a passive reading of your messages (such as accessing the mailbox of the target), performing a MITM on a key exchange is noisy (and likely more illegal), and will put the victim in paranoia mode if discovered. Thus, unless you are a high profile target, I don't think it would be sensible to fiddle at that level (you may be considered more important than expected, though and there are stupid attackers, too).

So yes, exchanging your keys via unencrypted email is a workable solution. But do your part and try to verify them.

Beware: if dealing with non-technical people, many technical people and generally, expect lots of “how to use this?” basic questions, people mailing you their private key with the public one, etc.

Some ideas:

If you are going to exchange only PGP mails, you could automatically filter as spam everything not signed/encrypted to your key. (Spam issue)

As the email existence is intended to be secret, you could use a random email address such as <fingerprint>@domain (only one piece to transmit, instead of email + fingerprint). On the plus side, this forces your correspondent to get the fingerprint right if they are going to start the communication. On the con side, homograph attacks are easier.

I guess this system is indeed used by privacy-conscious [government] people. Publishing keys/fingerprints in https pages is also common.

As much as the X.509 system can be more suitable for such organization, I don't think they will be using them. There's also the duplicity if they are using OpenPGP for other correspondents. And of course, a secret agent in a covert mission wouldn't be using a X.509 key -nor email address- identifying him as such. ;)

PS: Run gpg --search nsa.gov for some funny keys published in the keyservers.