I've been learning about PGP, and I asked myself, "Why?"

For example, if I'm using https://mail.google.com, then what benefit would adding PGP offer that would justify it being used?

I can understand that its possible for an encryption method to become compromised, and it could be seen as a means to avoid disaster if a backdoor to SSL/TLS was released. PGP is also more decentralized, which could be attractive to some.

  • 6
    Uhm… you send mail with SMTP, not HTTPS…
    – mirabilos
    Commented Dec 13, 2014 at 14:42

7 Answers 7


SSL/TLS protects the email from tampering or eavesdropping as it transits between your computer and Google's server, and possibly during further relays to eventual recipient. And that's all it does.

PGP does far more. If you're sending a signed email, the recipient can verify that the email was sent by you, and that it was not tampered with at any point between when you wrote it and when they received it. If you're sending an encrypted email, you know that nobody but the intended recipient can read it -- not Google, not the NSA, nobody. That's why it's called "End to End Encryption".

However, the email metadata (from, to, subject, timstamps) is still sent in clear, and PGP can't help with that. So in general, it's best to send PGP-encrypted emails via TLS-secured connections.

  • 18
    For completeness... PGP leaks information in when used in email. It can't encrypt the headers. So the Google and the NSA gets to build a graph of friends and associates, and they get to see what you've been talking about (or what you've been trying to hide).
    – user29925
    Commented Dec 11, 2014 at 9:33
  • 8
    @jww They only get to see what you've been talking about if you put "Our secret plan to topple the Taliban" in the Subject line. If you instead put "Grandma's top-secret muffin recipe" there, then no, they don't know that you're actually talking about Grandma's top-secret chicken pot pie recipe!
    – Kromey
    Commented Dec 11, 2014 at 16:33
  • 24
    @Kromey: jww's bigger point is that they can see that you emailed Joe, Alice and Bob. Alice also contacts Pete often and Pete happens to be associated with terrorist group X. When you sent that "grandma's top secret recipe", 5 minutes after "POP'ing" the email from the server Alice fired of an e-mail to Pete and 2 hours later the bomb went off 3 blocks away from you. The point being: even though the actual message (rather: body) of the e-mail can't be read; there's a whole lot more you can't (easily) hide and which PGP doesn't solve.
    – RobIII
    Commented Dec 11, 2014 at 17:07
  • @RobIII Sure, and I didn't/don't contest that (well, other than that the simple fact of communicating via encrypted channels is not incriminating...), I was just pointing out that "what you've been talking about" is only available if you make it available, i.e. put it outside the encrypted medium yourself. That you talk to Alice is of course available, and I never argued that; what you said to her, however, is not -- not unless you (or her) screw up.
    – Kromey
    Commented Dec 11, 2014 at 17:22
  • 3
    This doesn't address the point of how email is sent via SMTP, not HTTPS. Sending an email through Gmail does not mean the email is sent encrypted. It just means that your connection to mail.google.com is encrypted. Google still has to relay the message over SMTP, which is a very insecure protocol.
    – Brandon
    Commented Dec 14, 2014 at 15:39

There is more at risk in using SSL/TLS than potential 0-days, because there are already known attacks that can circumvent TLS. Moxie Marlinspike has been giving Def Con presentations on it since at least Def Con 17.

One of the most notable tools is sslstrip, created by Marlinspike.

Sslstrip works because TLS operates on a Certificate Authority trust model, which gives potential MITM adversaries an opportunity to forge digital certificates and serve them to an unsuspecting user. The user's browser will tell them the website might be insecure, and most will continue anyway. When properly used, TLS is considered secure, however older versions such as SSLv2 and SSLv3 have been proven to be insecure.

This is problematic because the default behavior of TLS is to fall back on SSLv3 when one end of the connection does not support TLS. With this, an attacker can force a users connection to SSLv3 without them knowing. A patch was released, however does not mitigate the issue, as both ends of the connection must be patched. This means that unless you go out of your way to disable SSLv3 entirely, your encrypted communications are still at risk.

With PGP/GPG, the bar to entry is much higher. You cannot simply fire up your web browser and start typing. In fact, PGP is not used for encrypting traffic at all. It is used to encrypt data while on your computer, which you can then send. It has remained largely unchanged over the years, and is often complained about for being difficult to set up for beginners. With proper usage however, it is a very secure method of encrypting communications. So secure in fact, Ed Snowden has recommended it to evade the NSA.

The biggest difference between TLS and PGP is that with PGP, the data is secure on either end, where in TLS, the data is only secure during transmission.

The key to getting the most out of PGP is to generate a good key, establish your web of trust, keep your private keys secure, and assume if your machine is compromised that your private keys are as well. (Which you would then use a previously generated key revocation certificate to nullify the key)

For more info on getting the most out of PGP/GPG, try checking out a comprehensive resource on it. This is one of many created over the years.

  • 4
    +1 for mentioning web of trust, as that is a large advantage of PGP to me. I would focus more on this aspect in my answer. Concerning the securing on both ends: I could also authenticate myself with a client certificate over SSL, which would make it sure for both parties they are communicating with the correct person. Concerning SSLv3: the SSL3 issues are issues that can occur in any protocol.
    – Michael
    Commented Dec 11, 2014 at 9:13
  • 1
    Mechanisms like HTTP Strict Transport Security and browsers implementing STS preloaded list deal with sslstrip to some extent. And with certificate pinning, the CA trust model is a little more trustworthy. Commented Dec 11, 2014 at 9:15
  • Feel free to suggest any edits to clean it up a bit, I know my understanding is somewhat solid but not complete by any means. Commented Dec 11, 2014 at 9:17
  • @Michael What do you mean by SSLv3 issues being able to happen with any protocol? Do you mean any application-layer protocol that uses SSLv3 for encryption? Certainly, there were several vulnerabilities in SSLv3 that are no longer issues with TLS 1.2
    – reirab
    Commented Dec 12, 2014 at 17:23
  • @reirab , no I just meant that with any cipher(suite) bugs/issues/vulnerabilities might come to light, also for PGP, which is why that is not really a valid argument against https.
    – Michael
    Commented Dec 12, 2014 at 17:27
  1. non-repudiation -- no one can forge your private key signature of a message,
  2. encryption at rest -- the message is encrypted not just in transit, but at rest as well.
  3. all of the benefits of mail over SSL/TLS sans a lot of the problems (e.g. Heart Bleed and POODLE)

Just to name three.


HTTPS only protects your email between you and Google. From then on it is transferred unencrypted. That means your email can be read by:

  • Google (and they admit that they read it!)
  • any routers between Google and the mail service of the receiver
  • the receivers mailserver
  • when the receiver isn't also using https, any router between their mailserver and them.

PGP, however, provides end-to-end encryption. Only the receiver can decrypt the email. All intermediates can only relay the encrypted text without being able to read it.


In short, PGP protects the contents of the email, both in-flight and at rest; TLS protects the communication channel while the message is transiting a network.

PGP vouches for a person and an email address; TLS vouches for a server (and optionally a client).


Unluckily, although PGP is awesome in theory, the "real world" benefits of PGP are quite limited, if existent. If PGP was the default that everybody uses, it would rock.

TLS gives you (ignoring the possibility of exploits) a secure connection to your mail server. You have the guarantee that the server you talk to is really your mail server, and that nobody can eavesdrop on your communication with the server. However, there is no end-to-end encryption, nor message authentication.

Which means that although your communication with the server is confidential, your messages are stored in plain text on the server (and forwarded to the NSA anyway, don't be fooled into believing anything different).
Also, the exchange with the recipient's mail server may or may not be secured (you don't know), mail on the receiving (and intermediate) server(s) is stored in plaintext, and the recipient may or may not use a secured connection with his mail server.

Further, despite some extensions that thwart the most trivial spoofs, the protocols used in email exchange are pretty naive and give little to no guarantee about a message's origin. In other words, you do not know with any reasonable certitude whether a message you received originates from who you think it came from at all, or whether someone replaced part of it with something different.

PGP addresses all of this in theory by offering both end-to-end encryption and a means of signing messages. That means you know for sure that the message you received cannot be read by anyone intercepting the message, and the message really originates from who you think it came from and wasn't changed.

The problem is that for this to work, two prerequisites must be met:

  1. The other person must use PGP.
  2. You must have the other person's public key and you must be 100% certain that this is the genuine key.

The first point already pretty much settles PGP's benefits for the "real world". Hardly anyone uses PGP. Your aunt Sally doesn't, your bank doesn't, your electric supplier doesn't, and XYZ doesn't either. Which means you just aren't getting to use PGP, except with a few geeks.
The second point bears the whole lot of problems that SSL/TLS has, too (as explained e.g. in that Defcon Youtube video in cremefraiche's answer), except the chain of trust in PGP is more of a "hobbyist" thing, if I'm allowed to call it that. This may actually be a good thing, but it may as well be a bad thing. Instead of trusting a company that sells certificates for profit, you let your keys sign by a number of... well... people. People you know well, or maybe don't know too well. Depending on who signed their keys, you trust them a little bit more or less.
Unless you meet the recipient at least once in person to exchange keys, you never have a guarantee that you own the correct key (either way).

PGP will hide what you are telling someone, but it will not hide who you mailed, or that you sent a mail at all (well, it can hardly do that, can it). The mere fact that you communicate with people may however already be important (even more so if you communicate using encryption).

An important consideration is that since the vast majority of people doesn't use end-to-end encryption, you are automatically on the bad guys' (bad guys = government agencies) suspect list if you do. After all, if you use encryption, you have something to hide, so you are most probably a crimial, or worse. No such thing as a presumption of innocence exists, outside fairy tale books (even if your constitution says something different).

So, when you plan your next bomb strike, it is probably a good idea not to coordinate your terror cell's weekly meetings via email and use PGP because the NSA will make you a priority target. That doesn't automatically mean you will get waterboarded, but it means that you will be subject to much more detailled profiling and a much more thorough individual analysis.

Depending on what their profiling shows (depending on where you live, who you talk to, what happens on your bank account, where you travel to, what communication pattern you have, etc.), this may result in anything from "nothing happens" to "guys with masks beat the crap out of you so you reveal your passwords" or "wake up in a black camp".
Luckily, for most people, it's the "nothing happens" flavor, but you never know.


Seven years later, and it seems like a better question would have been "What real-world benefits does sending email with SSL/TLS have?"

This 2015 paper looked at over 650,000 mail servers in Germany, which offered SMTP on one or more of ports 25, 465, or 587. 419K of them offered SMTP on port 25, but only 69% could perform a successful TLS handshake. 256K offered SMTP on 587, with 83% performing a successful handshake. On 465, the figures are 267K, and 90%. Now consider that most emails go through multiple hops, and TLS has to be negotiated on every hop. Clients appear to be unlikely to reject connections if the handshake fails, so the hop falls back to clear, and the remaining hops go through in clear. The paper goes over multiple reasons why TLS might fail, but it doesn't cover attacks per-se, and the most obvious attack is for a MITM to simply drop a STARTTLS, which would be relatively trivial.

So, unless you know that the sender's MTA connects directly to the receiver's MTA, with no intervening hops, and that both support TLS and are correctly configured, and that they haven't been compromised, and that both the sender and receiver are connecting securely to their own MTAs, then SMTPS appears to be completely pointless. In any event, you should never trust it. And, if you really were concerned with security, why would you go to the bother of auditing your SMTPS connection at all, rather than just using a custom protocol?

PGP has none of these issues, with the only downsides appearing to be that the addresses go through in the clear, and it's marginally harder than trivial to set up (Thunderbird, at least, has it built in now). And the NSA knows you're using it, of course.

You must log in to answer this question.

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