How should I distribute my public key?

Question

I've just started to use GPG and created a public key. It is kind of pointless if no-one knows about it. How should I distribute it? Should I post it on my profile on Facebook and LinkedIn? How about my blog? What are the risks?

Answer 1

Best way to distribute your key is by using one of the key servers that are available, such as keyserver.ubuntu.com, pgp.mit.edu or keyserver.pgp.com.

If you use Seahorse (default key manager under Ubuntu), it automatically syncs your keys to one of these servers. Users can then look up your key using your email address or keyid.

If you wanted to post your public key on LinkedIn or your blog, you can either upload the key to your server or just link to the page for your key on one of the keyservers above. Personally, I would upload it to one of the keyservers and link to it, as it is easier to keep it up-to-date in one place, instead of having the file in loads of different locations. You could also share your keyid with people, and they can then receive your key using gpg --recv-keys.

If you wanted to post your public key on Facebook, there is a field to place it under the Contact Info section of your profile. You can also change your Facebook security settings to use this same public key to encrypt their emails to you.

For example, here's my public key.

To my knowledge, there are no risks associated with publishing your public key.

Answer 2

There is no risk of exposing your private key or invalidating your public key, by publishing your public key in the ways you and @Mark described. As @pboin stated, it is designed to be available to the world.

However, there is another issue at hand... One of the core purposes of having and publishing your public key (indeed, this is probably THE MAIN purpose), is to authenticate yourself to other users, enable them to verify the authenticity of any messages or data you sign, and protect/encrypt data for your eyes only.
But how would those users know that it's really YOUR public key? For example, if I want to send a private message to @Mark Davidson, using his published key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE493B06DD070AFC8, how do I know that it was the REAL Mark Davidson that published that key or that pointed me there?
It would be trivial for me to publish my OWN public key, either on mit.edu, on LinkedIn, Facebook, etc, and simply call myself Bill Clinton (or Bill Gates). How could you know otherwise?
Moreover, if somehow I know this is really the right person (e.g., I want to contact an anonymous blogger, via the pk published on his blog - I don't care who he really is, the owner of the site - and thus the pk publisher - is the correct person anyhow) - what's to guarantee the public key was not tampered en route? All the links and sites mentioned so far (ok, with the exception of the PGP keyserver) are HTTP - i.e. no channel protection, i.e. can easily be altered between server and browser.

When using the X.509 / PKI model, there is always somebody trusted that vouches for you. E.g. a well-known Certificate Authority (trusted because the browser vendors vetted them, and added their root certificate to the Trusted Roots Store in the browser) verified your identity, and signed your public key/certificate. Thus, anyone who wants to verify you are who you say you are, can simply check the signature, and then check out the identity of whoever is vouching for you (and then repeat until finding the well-known trusted root CA).

However, in the PGP model, there is usually no central, trusted authority (though current versions DO allow this). Instead, PGP is based on the web-of-trust model, wherein if you trust someone, they can vouch in turn for someone else's identity.

Regardless, just putting your public key out there does not help anyone verify your identity, nor ensure that encrypted messages will be viewable by the correct person only.

What you CAN do:

• Publish your public key, much as you and @Mark said - but then provide a public-key token (basically a hash of the public key, like a fingerprint) via a secure channel. E.g. this is now short enough to read over a telephone if he knows you personally... I've even seen someone put his pk token on his business card, handed out a conference (admittedly this was from a vendor).
• Start signing your emails, then verifying to the recipient that it was your signature through an out-of-band channel (e.g. over the telephone or in person (gasp!!))
• Complicate the situation, get a standard X.509 cert and implement SSL (preferably EV) on your website, then anyone can download your pk safe in the knowledge that it came from whoever owns that domain name... (Okay, maybe that works better for big companies...)
  Check out how Microsoft does it...

Aaaaall that aside, it really depends on what this pk is for - if it's just to wow your mother, then don't bother with all that :)
On the other hand, if you have really sensitive communications, or with security-conscious clients, then all the above is important...

Answer 3

A general solution is to upload it to a keyserver. Another good idea might be to make an entry at Biglumber. This helps to get in contact with other people and maybe to sign each other keys.

Furthermore you should have a look into your inbox and look for contacts who already sign their emails. You could send them an informal mail, that you now have a key and point them to a resource.

A blog entry about your key is also fine. You should provide a link to download your key.

If you use signatures in your mail, you can point to your new key and of course sign every mail.

Remind that you can't delete your key after it is uploaded to a keyserver (and distributed amongst them). Of course, you can revoke it. Furthermore it is assumed that spammers look for those email addresses and send you some "nice offers". When you do keysignings and upload the new signatures, the signature reveals where you've been at a specific date.

Answer 4

Be aware, any email-address on your key will be shown on public webinterfaces. I get a lot of spam on the email on my key, so it did not put my current email address on the key.

Answer 5

The distribution of the public key is still an open problem with PGP/GPG.

Upload to a public keyserver

• others can sign your key public with an insulting text or content you do not want to see in connection with your key
• many users forget the password, or lose the revocation key and changed their mail address and can not remove the old key anymore.
• it is nearly impossible, to remove a key or signature ever from these servers
• data mining tools to analyze data from a keyserver do exist
• one gets a little more spam to the addresses on a public keyserver because they are easy to crop and very interesting because they support lots of metadata: Such as name, mail, friends, timestamp.
• ...but everybody can upload your public key to a keyserver. This may happen by intention, or by accident. Most PGP tools support uploading imported public keys and if you wait long enough somebody will upload it and sign the key without knowing you.

Upload to own website

• the user can remove or change the key
• downloading a key from a trusted website of the recipient can be another indicator for an authentic key
• many professional users of PGP chose this method (too)
• placing the key next to the contact on your website advertises the usage of PGP

Personal meeting

• a possible attack is to plant a fake key. Paranoid people meet in person and exchange keys printed on paper.

• this might be in a QR code on your card (quite famous); see Is there a standard for printing a public key as a barcode?

For further reading see

• http://secushare.org/PGP
• http://en.wikipedia.org/wiki/Key_server_(cryptographic)
• http://cryptome.org/2013/07/mining-pgp-keyservers.htm

Answer 6

The simple answer to your "distribution" question is that you should use whatever method works conveniently for you and your intended recipients, and meets your needs in terms of privacy. E.g. a keyserver can conveniently be used for distributing to many recipients, but as ubi notes a typical keyserver exposes the uid (which typically has your email address) to spammers for all time.

The much harder question is how does your recipient verify that they got the right key for you, rather than something forged which facilitates an attack? You may want to exchange a fingerprint of the key with the other person "out-of-band", e.g. over the phone. Or you can rely on the "web of trust": a chain of signatures of people you trust for the purpose. See these questions for more tips:

• Shouldn't GPG key fetching use a secure connection?

• What risks are inherent with connecting to an untrusted public key server?

Answer 7

For distribution, it really depends on your audience. The optimist in me hopes that people will be eager to use my key to encrypt messages and check my signatures. The reality is that managing it has been a non-problem. I've done very well by offering it on my blog and on request.

As for the risks, it's designed to be readily available to the world. Focus those concerns on safeguarding the private key. Put a password around it, and guard it carefully.

Answer 8

In Linux, you can use the command:

$ gpg --keyserver hkp://keyserver.ubuntu.com --send-key "your key_index or email"
$ gpg --keyserver hkp://pgp.mit.edu --send-key "your key_index or email"
$ gpg --keyserver hkp://pool.sks-keyservers.net --send-key "your key_index or email"

And sent it to different servers. They will propagate your key.

Answer 9

I'll one additional risk with a very specific context, post leaking your private key.

Assuming lots of private keys have leaked to some attacker (possibly millions) in a distributed WannaCry style attack then your public key can be used to both identify you as a target (find the servers to which you have SSH access via the public key) and find the private key in the large collection of stolen key pairs when trying to crack open a new server not affected by the initial attack.

We're also assuming you don't immediately learn your keys were stolen so you can remove access and regenerate.