If I run this for example:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451

then does the importing occur in a secure way? I mean does it go over only secured connections? (HKP?) Could it be compromised because the key fetching doesn't use end-to-end encryption+proper authentication (MITM attack)?

UPDATE: So I'm asking exactly this: when I want to grab someone's public GPG, then could it be attacked with MITM? (So that the attacker hijacks the "connection" and it spoofes the keyserver.ubuntu.com to an ip that he ownes, and gives a false public key, and when I check it with GPG then I will contact the bad GPG keyserver, and it could look like that the GPG key is valid!)

  • 1
    Again, you're not clarifying what kind of "security" you're focused on. It's important to clarify what assets, threat model, etc. as the faq advises. Do you care if someone knows whose keys you're looking for? Or just whether you know who is responsible for some pgp-signed software you downloaded? Really - please read the faq. If it isn't clear, ask questions about it in meta.security.stackexchange.com. Without clarity on that stuff, we all risk just going around in circles.
    – nealmcb
    Commented May 29, 2011 at 0:24
  • i updated it! thx Commented Jun 3, 2011 at 6:54
  • I updated my answer. Note that a key does not refer to any particular keyserver, and when you check the key and the signature path from your trusted key to any given key, gpg doesn't need to trust any keyserver. So don't worry about that, even if someone does do a MITM on the keyserver. Though I do address other reasons why you would want a secure connection. Let me know if it isn't clear.
    – nealmcb
    Commented Jun 3, 2011 at 15:35
  • 3
    The alertness which is reflected in the question is great. The concern that is raised here is imho not to be neglected. After all spoofing+MITM keyserver-client communication can be a valueble way for attacks (and a possible one - given a lack signatures to make a trusted path). Commented Jan 4, 2013 at 7:18
  • 1
    FWIW, I've seen keyservers with hkps:// for the protocol.
    – forest
    Commented Feb 17, 2018 at 4:43

6 Answers 6


It depends on your definition of "compromise". The main concern is privacy, for which parcimonie and tor are solutions, as noted below.

But first lets look at data integrity.

The notion of "end-to-end" security is most helpful when it covers the actual application you have in mind for the data. Since the objects moved around by the OpenPGP HTTP Keyserver Protocol (HKP) are covered by signatures based on public-key technology, they can be checked by your application (e.g. gpg) itself. It will establish whether the signatures are valid, whether they apply to other keys and people you trust, etc. (Update: So gpg only (optionally) gets the certificates from the keyserver, it does not rely on any keyserver to establish the validity of the keys.)

For example suppose you're using gpg to check signatures on email. If gpg tells you a given key is not known, you fetch it from a keyserver. Perhaps your mail then tells you the key is known but not trusted, since there isn't a trusted path (e.g. leveraging wotsap) from your ultimately trusted keys to the one that signed the email (like this one). So you look at the signatures, and find the key of someone who is trusted by someone you know, and who trusts the given key and download that too. If you end up with a path you trust, everything is great. If someone mucks with the keys while you're downloading them, you either won't get a trusted path (due to broken or unhelpful keys), or (and this would be pretty unusual) you'll get another path that might or might not work for you. The point is, though, that you still have to use gpg to check the paths, and evaluate the "intangibles" of the trust path yourself (how much you trust people and their understanding of signatures, etc). But you always have to do that with PGP. It is thus "end-to-end" in the sense that it is secured all the way from the person who made the signature, to your software which checks the signature, and your configured trust roots, and is thus pretty much ideal.

The security of the transport is not particularly important, and using TLS and the associated PKI and certificates would add extra complexity, cost and brittleness to the PGP keyserver infrastructure, without improving data integrity. If someone messed with the transport, they could deny you service, or do something like a phishing attack, but you nearly always have to deal with those sorts of issues anyway.

See e.g. the "Security Considerations" section of the (expired, but presumably still useful) Internet Draft on the subject: draft-shaw-openpgp-hkp-00 - The OpenPGP HTTP Keyserver Protocol (HKP)

A much more significant data integrity concern would be the risk of being fed a carefully crafted "malware certificate" that can exploit a buffer overflow vulnerability in your gpg client, or something like that. I haven't heard of any such exploits in gpg, but they have happened for SSL: yaSSL Certificate Processing Buffer Overflow Vulnerability - CNET. This is explored more at What risks are inherent with connecting to an untrusted public key server?

Update: A more problematic concern is privacy. If you don't want people to be able to see what keys you are searching for, or to mess with your key transfers, using TLS would be an alternative. But it doesn't protect you from the server knowing what you're interested in.

@teris-riel expands on the privacy concern: Imagine someone sends you a signed then encrypted email. Your mail client happily retrieves the key for the signature. Evan is watching the traffic and sees the key fly by. Now he knows 1) that you can read messages encrypted with the key he sent to, 2) that you did read that particular message, and 3) the approximate time you read it. If this kind of confirmation attack worries you, use hkps and Tor to get keys, and don't do it automatically. parcimonie is a tool that works to solve this problem.

And as a parcimonie implementation in bash notes: gpg --refresh-keys discloses your entire list of PGP keys to the keyserver you are using, as well as whoever is wiretapping your connection if you are using an unencrypted protocol such as HKP (which is the default for most setups). That is a bad thing.

So use something like parcimonie.

There are some alternative protocols, but finding servers for them which contain the keys you want seems hard:

See also

  • +1 : I hadn't seen the draft-shaw doc before. Quite useful.
    – Rory Alsop
    Commented May 28, 2011 at 20:36
  • so because hkp uses only HTTP then it could be a target of mitm, and the actual key could be modified so that using hkp in reallity isn't secure? Commented May 28, 2011 at 20:46
  • Hopefully my latest edit clarifies that. But note that you're still not clarifying your assets, threat model, etc. as the faq advises. Really - please read the faq. If it isn't clear, ask questions about it in meta. Without clarity on that stuff, we all just go around in circles.
    – nealmcb
    Commented May 28, 2011 at 21:05
  • @nealmcb: If I do not have signatures which allow me to make a trusted path (to the public key received) then I dare there is benefit me<->keyserver com encryption. I am sad people (mostly those who are already well in the WoT) tend to neglect those use cases where there are too little signatures on hand and hence the secure keyserver connection can prevent a MITM (which in that case is possible). Commented Jan 4, 2013 at 7:12
  • 2
    Imagine someone sends you a signed then encrypted email. Your mail client happily retrieves the key for the signature. Evan is watching the traffic and sees the key fly by. Now he knows 1) that you can read messages encrypted with the key he sent to, 2) that you did read that particular message, and 3) the approximate time you read it. If this kind of confirmation attack worries you, use hkps and Tor to get keys, and don't do it automatically. parcimonie is a tool that works to solve this problem. Commented Sep 4, 2013 at 22:42

There is no point in using a secure connection to the key server, because you should not trust the key server either.

In OpenPGP (the protocol that GnuPG implements), you gain trust in a public key by virtue of that key being signed by someone whose public key you trust. This is recursive, so the idea is to get a chain of keys, each signing the next, from a key you know absolutely (basically, your key, or the key of someone you physically met and who gave you his public key at that occasion) to the key you want to use. This is a kind of Public Key Infrastructure known as Web of Trust. The "public keys signed by other people" are actually "certificates". How you obtain certificates has no influence on their security, since you will use only certificates for which you could verify the signature. Thus, they can be stored on a public server which is not assumed to be especially trustworthy, and transmitted in cleartext without protection.

Actual security in a WoT is achieved by find several (many) validating paths; a single path is not enough. This is because getting sure that key K belongs to Bob does not necessarily imply that whatever key K' signed by Bob really belongs to whoever Bob believes it does. In X.509 terminology (another PKI standard), a WoT is like "everybody is a Certification Authority". This does not work well because Bob could be gullible, or maybe prone to recklessly sign other keys after his third pint. This is mitigated by requiring an overdefined set of certificate paths, i.e. the key you want to use is signed by many different Bobs, on the assumption that making a fake key (i.e. a key with the wrong identity, but nonetheless signed by other people) would require too much effort (or too much beer) from the attacker.

On the whole, the PGP worldwide WoT does not work well. What works well is exchanging keys through any insecure medium (a key server, simple emails...) and then phoning the key holder and exchanging the "fingerprint" (which is a hash of the key). Some people include their public key fingerprint on their business card. Basically, a direct certification without going through a Bob. This is how OpenPGP gets used most of the time, and that's fine.

  • 1
    Using TLS still requires you to trust the keyserver (e.g. to protect the private key of it's X.509 cert). But this more reasonable than blindly trusting the path between you and the keyserver. Mostly this is a problem of who is watching and why they may be interested in your social graph. (It's only "metadata".) TLS can help mitigate this exposure. Commented Sep 4, 2013 at 23:20

Most people seem to talk about PGP keys when they actually talk about PGP certificates. (Chapter 1 of the document Introduction to Cryptography in the PGP 6.5.1 documentation doesn't use the expression "PGP key" but "PGP certificate".)

Just like X.509 certificates, the security value of the PGP certificate is in its signature(s) and the ability of its consumer to bind the signer to an entity it knows and trusts. The main difference between X.509 and PGP certificates is that an X.509 certificate can only have one signature and issuer (hence it's part of a hierarchy), whereas PGP certificates can be regularly updated with additional signatures, asserting the binding between the public key and the identity. (As far as I know PGP certificates are always at least self-signed, which doesn't guarantee much. EDIT, thanks to @nealmcb)

Getting the certificate over a secure transport mechanism wouldn't add much (as @nealmcb said). What matters is to be able to be able to chain it back, using its signatures, possibly via intermediates, to a signer you know and trust. Of course, just like with X.509, there needs to be a "leap of faith" (or "dictated" corporate trust) when you get to the top.

If keyserver.ubuntu.com was serving its keys over TLS (assuming with an X.509 certificate), you would certainly know that the PGP certificate you were looking for hasn't been compromised between the server and you (provided you trust the issuing CA for its certificate). However, if you trust the key because of this, you would end up mixing two models: it's not because a key server hosts a PGP certificate that it makes any assertion regarding how you should trust its content. Key servers are just repositories of certificates.

  • 2
    No - many PGP certs are not self-signed. Sad and dangerous, but true.... The stats were actually very bad when I analyzed them in 1996: bcn.boulder.co.us/~neal/pgpstat
    – nealmcb
    Commented May 28, 2011 at 21:11
  • Well, the question is about gpg, which uses the term "key" instead for commands and documentation. But you're right that they're actually usually talking about what are commonly known as certificates, i.e. keys plus related signatures and metadata. I'm guessing that after the commercial PGP folks went to a GUI, they moved away from the historical PGP documentation and api which uses the term key instead.
    – nealmcb
    Commented Jun 3, 2011 at 18:50

Your danger here comes in the form of spoofing of the remote location, and this is most likely to happen via DNS which isn't helped by switching to HTTPS.

I would say that your best option here is to download regularly but manually confirm with the recipient that the key is correct.

  • 2
    @lance If you already have a secure channel with the owner of the key, then that is a fine way to verify that you have the right one, e.g. by confirming the key fingerprint (a hash) over the phone. But typically the reason to look for a key in a keyserver is because you don't already have a secure channel with the owner of the key. So how would you manually confirm it? That is where a trusted path (via the web of trust) comes in, as I describe in my answer. Also, https would help with dns cache poisoning, though it isn't foolproof given CA vulnerabilities.
    – nealmcb
    Commented Jun 1, 2011 at 17:24

Those are some long answers, so I'll try to be brief: a secure connection provides two advantages:

  • Data is hidden from a 3rd party
  • Data is authenticated so it cannot be changed by a 3rd party

Rarely (though possibly in some cases) is retrieval of a public cryptography key considered sensitive if exposed. It may be an issue if Eve is going to know way too much just by finding out that Alice and Bob have swapped keys, but for all basic intents we don't need to hide anything from a 3rd party so we don't need to encrypt it.

The public key you're downloading is verified by its cryptographic fingerprint which would already be exchanged in order to be secure. As authentication is built into the keys (so much as you already know the fingerprint), the an extra layer of authentication beyond that would be superfluous.

Thus, when transmitted by plaintext, GPG keys are still secure. Whether transported by SSL, private courier, or spray-pained on the side of a wall, the authentication is integral to the key and its public exposure almost never presents a risk.


In short: I could be tricked because it's not using HTTPS.

because: HTTP could be "rewritten" on-the-fly (MITM) and from there, the attacker could give a false GPG server to me.

  • As clarified by the other answers, one should not need to trust the keyserver - one should verify the keys by their signatures. Thus a MITM attack can do nothing more than interrupting the chain of trust (which could also be done by simply blocking a TLS connection). Commented Jul 3, 2011 at 1:32
  • @PaŭloEbermann It is a comofortable position to be able to verify the keys by signatures. It requires that the signatures you have already will allow you enough pathways. In the special case of a person having no trusted path, I wonder if it would be fair to say that MITM attack is a risk that can be neglected? There is the HKP (un-) and HKPS(encrypted) protocol. I assume the later one is there for a reason. Commented Jan 4, 2013 at 7:06
  • @humanityANDpeace In the case where there is no trusted path to (the key of) the sender of your message, you can't even trust that the message is really from this person. (The same is valid for encryption keys, with sender → receiver.) Anyone can upload a key with any name to the key server, and anyone else can express trust to this key, whether or not the connection is secured by TLS. The encrypted version of the protocol is there so nobody (other than the keyserver) knows which keys you request, I suppose. Commented Jan 4, 2013 at 18:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .