55

I've been trying to figure out "practical encryption" (AKA "PGP") for many years. As far as I can tell, this is not fundamentally flawed:

  1. I know Joe's e-mail address: cool_joe@gmail.com.
  2. I have a Gmail e-mail address: me_78@gmail.com.
  3. I have GPG installed on my PC.
  4. I send a new e-mail to Joe consisting of the "PGP PUBLIC KEY BLOCK" extracted from GPG.
  5. Joe received it and can now encrypt a text using that "PGP PUBLIC KEY BLOCK" of mine, reply to my e-mail, and I can then decrypt it and read his message. Inside this message, Joe has included his own such PGP public key block.
  6. I use Joe's PGP public key block to reply to his message, and from this point on, we only send the actual messages (no key) encrypted with each other's keys, which we have stored on our PCs.

Is there anything fundamentally wrong/insecure about this? Some concerns:

  1. By simply operating the e-mail service, Google knows my public key (but not Joe's, since that is embedded inside the encrypted blob). This doesn't actually matter, though, does it? They can't do anything with my public key? The only thing it can be used for is to encrypt text one-way which only I can decrypt, because only I have the private key on my computer?
  2. If they decide to manipulate my initial e-mail message, changing the key I sent to Joe, then Joe's reply will be unreadable by me, since it's no longer encrypted using my public key, but Google's intercepted key. That means Joe and I won't be having any conversation beyond that initial e-mail from me and the first reply by him (which Google can read), but after that, nothing happens since I can't read/decrypt his reply?
schroeder
  • 123,438
  • 55
  • 284
  • 319
Joas
  • 559
  • 1
  • 4
  • 3
  • 22
    Short answer: yes, that's secure. That's how public-key encryption works. It's ok for the public to know the key – schroeder Feb 23 '20 at 20:22
  • 53
    In the scenario that you describe, Google is in a position to pull off a classic man-in-the-middle attack (MITM), by intercepting messages between you and Joe, and replacing each of your public keys with their own public keys. See https://en.wikipedia.org/wiki/Man-in-the-middle_attack for how this works. – mti2935 Feb 23 '20 at 21:26
  • 44
    The standard additional step to eliminate the possibility of MiTM is to communicate **out of band** and verify each of your public key fingerprints with each other. In person is obviously best, but a phone call where you can recognize each other reading off the fingerprint is fine. So too is having others sign your key with their key, declaring that it is valid. – user10216038 Feb 24 '20 at 04:54
  • 2
    @schroeder In other words, it's secure if you assume Joe got the public key you sent him. – chepner Feb 24 '20 at 17:32
  • 1
    When it comes to gpg, I read somewhere you can put your public key on your business card and give it to people. that way when they send you an email using your public key, you can decrypt it using your private key. – Daniel L. VanDenBosch Feb 24 '20 at 21:13
  • as the name suggests, the public key is public – njzk2 Feb 24 '20 at 22:05
  • 1
    @mti2935 : but unless you are a very high-value target, or you are some kind of political activist who pissed off Google royally, the chance of Google pulling something like this is practically zero. – vsz Feb 25 '20 at 06:26
  • 4
    @DanielL.VanDenBosch Since the public key is rather large, the recommended way is to give out the key's id and fingerprint (e.g. on a business card or slip of paper). The other party can download the public key from a keyserver via the id or your name and verify it's the correct key via the fingerprint. – Martijn Heemels Feb 25 '20 at 10:19
  • @user10216038 phone calls can be faked using deepfake voices – Rsf Feb 25 '20 at 12:20
  • 1
    This is why we attend [key signing parties](https://en.wikipedia.org/wiki/Key_signing_party) (said no one ever). – erickson Feb 25 '20 at 17:31
  • Keybase does a very good job of solving this problem, by letting people prove ownership of external accounts. If you know that the person you want to communicate with is the same person who owns Github account X, verifying a Keybase proof of that account lets you know that the owner of that Keybase account is the same person who's making claims to own specific public keys (be they PGP keys or Keybase's native/preferred Saltpack). – Charles Duffy Feb 25 '20 at 20:45
  • @vsz, do you think GMail is secure enough that no third-party would do something like that? And I think you overestimate the integrity of one of NSA’s largest competitors. – WGroleau Feb 25 '20 at 21:51
  • 1
    @chepner, nit-pick: it’s secure if he received it, not if you _assume_ he received it. – WGroleau Feb 25 '20 at 21:53
  • 2
    @schroeder You should consider deleting your comment. The scenario described here is *not* secure. See the other comments/answers. – Jon Bentley Feb 25 '20 at 21:54
  • @JonBentley context matters. Gmail *could* target the bi-directional comms and change the keys, but that's not a credible risk – schroeder Feb 25 '20 at 22:01
  • 1
    @WGroleau Yeah, I think I meant something like "You can only assume it's secure if you can assume he received the correct key." – chepner Feb 25 '20 at 22:05
  • @DanielL.VanDenBosch: "put your public key on your business card" -- see [Putting my PGP ID/link on printed business cards](https://security.stackexchange.com/questions/70501/putting-my-pgp-id-link-on-printed-business-cards) – David Cary Feb 26 '20 at 02:11

8 Answers8

77

As Steffen already said, the Achilles' heel on your security is making sure you are talking to Joe, and Joe being sure he is talking to you. If the initial key exchange is compromised, the third party will be able to read your messages, reencrypt and send to Joe, and vice versa.

The crypto does not matter unless you solve this issue. That's why on the HTTPS world, there's a special entity named CA (Certificate Authority). The CA is to make sure Google cannot obtain a certificate for Facebook, and so on. So unless a rogue CA issued the certificate, you can navigate to Google, and be sure you are on Google.

The initial key transfer is the critical one, and this can be done in a couple ways:

  • in person
  • by out-of-band message (tweet, Instagram post, snail-mail)
  • referral by a friend in common (you know Bill, have his key saved, and Bill knows both of you, and shares both keys)

After this exchange, your setup is pretty solid.

John Kugelman
  • 139
  • 1
  • 8
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 11
    Even in the HTTPS world, there's an out-of-band mechanism: Google Chrome comes with a list of "pinned" certificates where it doesn't trust the CA's. – MSalters Feb 24 '20 at 10:36
  • 4
    Classic and quite reliable out-of-band mechanism is just a phone call. While easy to listen to, phone calls are quite hard to convincingly MITM in realtime. – jpa Feb 25 '20 at 06:15
  • 4
    @jpa and now I'm imagining somebody reading a base64 representation of a public key with the length of a 80 y.o. grandpa reading a phone number – bracco23 Feb 25 '20 at 16:47
  • 8
    @bracco23 I should have been more specific, verify the fingerprint over the phone, not the whole data :) – jpa Feb 25 '20 at 18:58
  • How exactly will the third party **re-encrypt** the message when they have only the public key? Didn't you mean forward the original encrypted message? – Mindwin Feb 26 '20 at 18:29
  • @MSalters There's another out-of-band mechanism: DNS CAA lets you specify which CAs are allowed to issue certificates for a domain. Of course this is out-of-band for HTTPS but relies on DNS being secure (a whole other kettle of fish). – Bob Feb 26 '20 at 22:54
  • Sounds to me like CA looks an awful lot like a pre shared set of keys. – Jon V Mar 04 '20 at 16:24
21

If they decide to manipulate my initial e-mail message, changing the key I sent to Joe, then Joe's reply will be unreadable by me, since it's no longer encrypted using my public key, but Google's intercepted key. That means Joe and I won't be having any conversation beyond that initial e-mail ...

As long as you can be sure that they can only man-in-the-middle the initial mail then this is true. But if they can man-in-the-middle the following mails too then they could simply decrypt the message from Joe to you because it was actually encrypted to them and can encrypt it again for you since they know your public key.

To setup secure communication for email you would need to have some other secure communication channel already to exchange or at least verify the public key since otherwise a MITM could simply claim these identities and nobody could detect this.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Let's say the MitM changes not only the key, but sends along a message saying _my current account was compromised, but I created this other account_... and it's signed by him (as far as you can tell). He does the same to Joe, and both are talking to each other (as far as you both can say), and to the attacker, who have every copy of every message you both exchange. – ThoriumBR Feb 24 '20 at 16:11
  • 1
    @ThoriumBR Yes, that is why out-of-band verification of the key signature is vital. If you can't trust a communication channel then there's not way to bootstrap secure communications over that channel. You need another channel to verify keys. GPG's web-of-trust was great for that, even if multiple degrees of separation removed from each other. A simple phone call to read out the fingerprints to each other is usually enough too. – Martijn Heemels Feb 25 '20 at 10:29
7

This approach is very secure as soon as you can trust the email provider (namely, Google).

All other answers on MITM attacks are true in general. In this particular case, when operating within the same provider, additional considerations can be made with success.

1. Joe can't be (easily) impersonated

Since a decade ago, anyone can send you a crafted email coming from "a guy named Joe", or even from donaldjaytrump@whitehouse.gov with what looks to be Joe's public key. Smallest providers (very, very, small email servers) might not enforce SPF policy.

Within the same email provider, and that is true for Gmail, additional checks are made to ensure nobody can forge a Gmail sender address. One has to hack Joe's account, which is out of the scope.

In short, assuming that Joe can't be hacked is enough to say that Joe can't be impersonated by malicious third party, and mail coming from Joe comes really from Joe from Joe's email account.

2. You (must) trust your own provider

Since you use the same provider, I have to assume that you trust it. No matter how Google, in this particular case, is trustworthy, from a security standpoint there is one attack vector left. The provider should be rogue enough to change Joe's public key with a forged public key to disrupt secure communication.

What I mean is that the only actor capable of breaking security of your conversation is Google Inc. themselves, because both of point #1 and because emails don't leave their own systems.

Answering your concerns

Google knows my public key (but not Joe's, since that is embedded inside the encrypted blob). This doesn't actually matter, though, does it? They can't do anything with my public key? The only thing it can be used for is to encrypt text one-way which only I can decrypt, because only I have the private key on my computer?

Assuming break of point 2, Google can impersonate you and alter your own public key with a key they know, and re-encrypt and re-sign the message at their will.

They have only one chance of action, and that is your first email "Hello Joe, this is my public key ABCDEF"

If they decide to manipulate my initial e-mail message, changing the key I sent to Joe, then Joe's reply will be unreadable by me, since it's no longer encrypted using my public key, but Google's intercepted key. That means Joe and I won't be having any conversation beyond that initial e-mail from me and the first reply by him (which Google can read), but after that, nothing happens since I can't read/decrypt his reply?

Google will have to eavesdrop and transcode the messages you exchange. If that happens, you won't be able to detect the attack, because both have initially put trust on the wrong key.

Email MITM example (with Alice, Bob, Charlie)

Charlie is a rogue email service provider

Alice (via Charlie):

Hello Bob, this is my public key ABC983 (attached key material)

Charlie generates a new keypair and replaces message

Hello Bob, this is my public key ZZZ765 (attached key material)

Bob receives the text, encrypts a new message with key ZZZ765, which is a rogue key, and stores ZZZ765 in his trust store. Then sends the following email to Charlie for delivery

Nice to meet you Alice, please use DEX258 as my key.

---Encrypted using ZZZ765, signed using DEX258---

Charlie intercepts the email, decrypts using ZZZ765 to get the plaintext, then generates yet a new keypair.

Charlie delivers the following email to Alice

Nice to meet you Alice, please use FGN754 as my key

---Encrypted using ABC983, signed with FGN754---

Alice will trust the rogue key FGN754 in their trust store.

Both parties will swear that they have genuinely talked each other securely until the day they meet at a bar, in person.

To their surprise, they will discover that they used the wrong keys and that the original emails differ from their "Sent mail" folder. End of the story

usr-local-ΕΨΗΕΛΩΝ
  • 5,310
  • 2
  • 17
  • 35
  • 1
    "ISP" should really be replaced with "mail service". You communicate with your mail service (Google) over TLS, so trust for your ISP (who simply provides the pipe between you and the internet) is not strictly necessary. – josh3736 Feb 25 '20 at 00:14
  • @josh3736 Without a special setup, all your DNS requests are sent unencrypted to your ISP. Your ISP can then return any IP address they like for google.com. – Fax Feb 25 '20 at 09:18
  • 1
    @Fax But unless your trust anchors have been compromised, your browser will detect the spoofing when it fails to validate the forged google.com certificate. You don't need trustworthy transport (ISP) to establish a secure channel as long as you possess the right keys. – erickson Feb 25 '20 at 17:30
  • @erickson True, but if the website doesn't use HSTS or is not in the HSTS preload list (which, granted, google.com most certainly is), you may be vulnerable to a downgrade attack. – Fax Feb 26 '20 at 12:23
6

In your scenario, the PGP key that you send to Joe can be manipulated in-transit, and Joe won't be able to notice it unless you make use of one out the following solution approaches built into PGP:

The initial public key exchange is crucial, but there are solutions to it. For X.509 certificates (as used for S/MIME), that same problem is solved using hierarchically organized certificate authorities. In that system, a certificate can be trusted if it is signed by a trusted CA. The PGP approach to it is the web of trust which more or less means that anyone can sign a key, and whether or not that signature can be trusted depends on your personal trust in the signer.

So to apply this mechanism to your problem, if your key is signed by a third party who is trusted by Joe, then it is impossible to manipulate the key in-transit in a way that would go unnoticed because the manipulator would not be able to sign the manipulated key in the name of the third party. Note that if the key is signed by a trusted third party, the key can be obtained from any source, and that is how PGP key servers are supposed to work.

If there is no third party that is trusted by you or Joe, then you can still send your public key to Joe, but you would have to verify that the key received by Joe has not been modified en route in another way. To do so, you can tell him your key's fingerprint, but you would need to do that on an independent channel. For example, it is not unusual to publish the fingerprint on a web site. Unless that web site is hosted by Google, it is very improbable that it could be manipulated to fit the manipulated key.

not2savvy
  • 710
  • 5
  • 12
  • The fingerprint on a website should not be trusted automatically if the matter is so important that Google is out to get you. All websites can be manipulated on the client side. The client is often Google's chrome, which can show whatever fingerprint it wants to whoever it wants. There's ways around it, but if Google's after you, some form of non-digital communication should be used to exchange the initial keys. Even this, just moves the trust pole forward. Ultimately you need to trust someone somehow. There's no 100% secure channel of communication. – Andrei Feb 24 '20 at 13:41
  • @Andrei, that's why I stated it is _very improbable_ which implicates that it is _not impossible_. However, if your client has been infiltrated, then of course anything goes, and it does not make sense to discuss encrypted communication any more. Therefore, when answering the question, it makes sense to assume that the client environment can be trusted. – not2savvy Feb 24 '20 at 13:49
  • What's the advantage of putting a fingerprint on a website when you can put the whole public key on the website instead? Well, I guess I can answer that! Putting the whole key would reveal your email address to people. – Brōtsyorfuzthrāx Mar 05 '20 at 23:28
  • @Brōtsyorfuzthrāx The idea is to verify the authenticity of the public key through a second independent channel. The fingerprint is short enough to even be verified over the phone. – not2savvy Mar 05 '20 at 23:32
3

It creates a one time opportunity for an attacker to MITM (man in the middle) your certificate exchange and offer a different one instead. Hypothetically they could intercept and forward every message you send re-encrypted with the new attacker key. There are several mitigating factors though.

If both of you use the webmail client for gmail, there is minimal opportunity for an attacker to mess with your email, even though SMTP is not actually super secure.

After the key exchange you will know you are mailing the same person, whether attacker or legitimate. It is essentially a trust on first use thing, there are no further opportunities for an attack to happen.

The attacker would need to essentially MITM all if your emails, if they constantly got lost it would be a red flag.

There are suggestions that they entire key needs to be exchanged in a secure channel, this is false. You can email the public key block and then call or meet in person to exchange the certificate thumbprint--a secure hash of the key--to verify that it is valid.

trognanders
  • 2,925
  • 1
  • 11
  • 12
2

As others have pointed out, in your scenario, Google is in the position to be a man-in-the-middle for your initial message sending your public key to Joe. One thing that can be helpful is to publish your public key in multiple locations. So, you publish your public key on your website (not hosted by google), on github and facebook and hacker news and reddit and stackexchange and on multiple public key servers, or on a billboard or an ad in the New York Times or a post in an anonymous newsgroup or a random forum or whatever (and in fact, services like keybase.io allow you to link a lot of those things to your pgp public key with a verifiable signature). Then, you can list all the places you put your public key, and sign the whole message with the same key. Google, or anyone else, is unlikely to be able to modify all those places.

However, since Google also owns a trusted CA, and Google's Chrome browser is also widely used, if Google wanted to target you, it seems possible that they could make their browser trust the altered version of any public site. To do this, they'd have to either issue another certificate to all the third party sites that listed your key (and Certificate Transparency is designed to mitigate this kind of attack), or they'd have to do a bit of post-download manipulation in Chrome, and even that would be easy to detect by comparing output in Firefox and Chrome.

Brian Minton
  • 1,136
  • 8
  • 15
0

That is correct. The public key is freely distributable. Anybody who has your public key can encrypt messages and send them to you. Only the private key (which you should never distribute) can decrypt the messages.

  • Public Key = Encrypt
  • Private Key = Decrypt

However, the limitation is if you send someone your public key they can only encrypt messages sent to you. This is a one-way encryption scheme and not totally secure since anyone can intercept and read the unencrypted messages you send to someone else. You would also need to obtain their public key to be able to encrypt messages you send to them.

A user may intercept an encrypted message but there is no ability to read encrypted messages using the public key as far as I know. I think what others are referring to is if you're communicating with Joe and a third user, Sam, is introduced. If Sam has your public key he could potentially send an encrypted message to you pretending to be Joe. You likely would still know that Sam isn't Joe because their public keys aren't the same and/or you don't have Sam's public key. If you tried to send an encrypted message back to Sam it wouldn't work.

Most casual users of email don't have a private/public key pair to send encrypted email. I'm sure even if they did it would promptly be blocked by their email provider and the NSA since there's no ability to intercept the message, read what's in there and gain the financial upper hand over them.

Justa Guy
  • 101
  • 1
  • "... * I'm sure even if they did it would promptly be blocked by their email provider and the NSA* ...". **Wrong**, just wrong! – user10216038 Apr 30 '20 at 15:51
0

Like many things in life, the answer is yes and no. Per your questions:

  1. You're right, there's no problem about the world knowing your public key - that's why it is called Public Key
  2. No, you're wrong on that. Since your service provider controls your service, it can act as a perfect Man In The Middle and intercept all your corresponding with Joe. Now, if your service provider intercepts those emails and stops them from reaching your inbox while Joe believes he's in a relationship with you and that the emails between you and him are private, and you think that there's nothing going on between Joe and you, well....now Joe is sharing his private thoughts with someone which is not you :(

Conclusion: You better send your Public Key via a different channel, a channel which can't intercept your conversations.

baba smith
  • 139
  • 3
  • This copies the other answers. Were you intending to offer a different perspective? – schroeder Mar 19 '20 at 12:06
  • @schroeder I meant to emphasize the second issue. I noted the first one just to not ignore it. If that was already explained then I must have missed that, that wasn't my intention. – baba smith Mar 25 '20 at 16:25