Employees of Facebook are geeky enough to use GPG. I suspect it was a feature built for internal users, but problematic now as most people don't understand it or are able to use it.
It’s at least a small intersection. I had it set up and I think it’s the only social media company that supported this.
Comically I forgot all about it until I had to reset my password and got an encrypted email. Was a pain to dig out my keys and decrypt it, but it worked.
I used mailvelope for the longest time as a gmail user until I found a better mail app with gpg support. It was pretty slick last time I used it.
Shamefully I also turned on the pgp messages from Facebook. I never found value with it, but to this day it’s still enabled and I don’t care to log in to Facebook to disable it.
It's possible to solve both the friction to start and stop using PGP by looking up keys automatically on the target domain, for example using WKD [1]. We (Proton) host a key for every user, which can be used to automatically end-to-end encrypt emails to all Proton Mail users, without any setup needed, nor risk of DoS (since the user can always remove their key from WKD). Various other providers also offer this [2].
Proton user here: I’ve an anecdote because it happened this week and support was unable to help me.
I’ve received a PGP encrypted email by a non-proton user. It worked fine. But I was unable to encrypt my reply to him.
Proton support told me that he needs to attach his public key to his message so I can use it.
It seems that the Proton interface doesn’t offer any way to automatically try to find the public key of an user (from which you have an email address and probably a signature).
We do look up keys automatically using WKD. However, if the non-Proton user's provider doesn't support that, they'll indeed have to attach it or you'd have to import it manually.
We have plans to also look up keys on keys.openpgp.org as well, to offer an automatic solution in case the provider doesn't support WKD.
Thanks for the clarification. I now understand better: I was confusing WKD and keys.openpgp.org as same thing.
As I received the email without the key attached and his domain doesn’t support WKD, I was stuck to manually import from keys directory. It makes sense.
Can you give a quick explanation for someone too dumb to understand your first citation?
I use pgp for years but struggle to understand how proton can say email is encrypted when I never have to decrypt it myself.
If proton has the key how is that different from Google just encrypting everything until right before it displays?
I used proton for a couple years but moved back to Gmail cause I figured all the encryption talk was just promotional and using pgp your self is the only way.
Proton does not have the private key material. When you sign up to Proton Mail, the client generates a key pair for you, encrypts the private key with your password, and sends it to the server, along with the public key (which we publish).
Then, when you log in, the client fetches the encrypted private key, decrypts it with your password, and decrypts your emails with the private key. All of this is done automatically but it's still end-to-end encrypted.
The first citation (WKD draft specification) simply describes how to publish (and look up) public keys for a given email address on its domain. So for twiss@proton.me (hypothetical example), the key is published at https://openpgpkey.proton.me/.well-known/openpgpkey/proton.m....
> I suspect this was a state actor funded operation, for this has effectively, and significantly reduced the usefulness of PGP/GNUPG.
If it was, they did us all a favour, because PGP as means of encrypting emails is a steaming pile of garbage, as it requires both, client support, and the counterparty to have the same OPSEC as you (e.g. not just forwarding the email unencrypted to someone else)
Email was never meant to be encrypted, and the existing implementations (including S/MIME) suck for this exact reason. And the worst thing is that it’s simply not possible to make it work.
HTML support client side, and required libraries are crazy complex compared to gpg integration. Yet that was done, and never meant to be.
Same for images inline, and the idea of attachments was an add-on. Other examples abound.
While I don't use html in my emails, it's effectively a standard now. So much so, that I have to prod some corporations to fix their stuff.
My point is, the "email was never meant" ship sailed decades ago. Change happens.
And there is no way to encrypt anything, ever, and send it to someone, who can't see it, and then copy it and send to others. A person can take a screen shot, or just take a phone and take a pic of the screen! So even if it's not simple, this problem is a non-solve, because if a human can read it, it can be copied to others.
Which means, I do not believe your criticism on this point is valid.
> PGP as means of encrypting emails is a steaming pile of garbage, as it requires [...] the counterparty to have the same OPSEC as you (e.g. not just forwarding the email unencrypted to someone else)
All encrypted communication protocols have this requirement. And all of them will in the future. By definition, you need the counterparty to be able to decrypt your message, which means you're always vulnerable to them forwarding the unencrypted message to anyone they want.
That only means it failed in its aim, and needs to be replaced with something better. If you really rely on encryption for something important, a system so easily broken is no good.
And "state actor funded"? Come on, the spam attack was absolutely trivial. It required no state funding, just a single person with an axe to grind, a target, and a trivial shell script. Attaching spam signatures was a thing decades ago already and didn't require any real resources of technical knowledge.
It's that, and the fact that a hacker would enable the feature after compromising the account (some other way, unrelated to PGP) to prevent the legit user from using the account recovery email.
So feature was basically there only to shoot oneself in the foot.
That is part of facebook's reasoning, as to why they dropped it. The second part should be kept in mind, and that is, few use it.
If it was popular, they wouldn't axe it.
My comment was certainly about facebook dropping it, but also about how this is a larger picture issue. You don't need to weaken encryption standards(NSA, others), or have back doors(loads of states), if people just find it too annoying to use!
Would have helped a lot of there would have been some sponsorship and adoption by banks, bigtech, governments. With only push from Snowden and a couple of nerds (I'm making a hyperbole :-) ) and it being complicated, inconvenient this never gained momentum.
Banks, bigtech, government choose other means, for their own reasons. Some of those might have been spies lobbying to hold on to their surveillance superpowers, for sure. Another might have been "not invented here".
For that to work, your email has to be compromised in the first place.
And if your email is compromised, well, it is game over already, for every single thing you have access to.
So it is just a poor excuse. I guess the main reason is that virtually nobody knew this feature existed and the intersection between the population privacy savy enough to use PGP and using Facebook is ridiculously small.
Hell, even amongst my peers, I'm continually shocked at how many people have never used gpg, ever. And, anecdotally, the number gets lower as age gets lower. Young people aren't using it. It's dying.
GPG sadly never grew up. It's a program firmly stuck in the 90s.
The original PGP manual talked about secretly communicating with your lover. That was the usage model, transmitting secret messages to people you could sometimes meet in person, and where the model was you talking to people you directly know.
Try to verify the GPG signature on say, the Tor Browser. It's signed by "Tor Browser Developers (signing key)". Have you ever met this "Tor Browser Developers" person?
Okay, what about the web of trust? Well, GPG offers no help whatsoever in finding a way of making a connection.
And that's why it's dying, because the model it targets ceased to be relevant, and we developed plenty new needs like verifying software signed by random people on the other side of the globe, while GPG did nothing to accommodate that use.
> and we developed plenty new needs like verifying software signed by random people on the other side of the globe, while GPG did nothing to accommodate that use
That's actually a really common use-case for GPG. I've seen it used for this more than for email...
I mean sure, there's a bunch of developers out there signing their code with GPG. But have you actually tried verifying it properly?
To verify the tor browser correctly, you need a trust path.
Option A: You've met at least one of them directly, and for some reason decided to sign a key with the label "Tor Browser Developers" on it. How did that person prove to you that they're a legitimate Tor developer? That's a pretty tricky thing to demonstrate.
Option B: You've signed the key of somebody who did the above. Same problem, but even more dubious.
Technically, GPG allows longer trust paths, you can do Alice -> Bob -> Carol -> Tor, or I think even Alice -> Bob -> Carol -> Dave -> Tor. But the software won't help you with this.
To do the first, you download the Tor key, look at who signed it, download all those keys, and hope that one of those might have a signature by somebody you know on it.
To do the second... you're on your own. You can do a brute force key download, where you download thousands of keys in the hopes of some connection being found, and blowing up the size of your keyring. This will add lots of random people into whatever UI you use and slow down every GPG invocation. And you'll need to write some sort of shell script for that, it's a pain.
Then you're using it wrong. GPG isn't adding anything to this that SHA256 wouldn't, and you're just relying on the SSL certificate.
Look at your list of CAs sometime. There's multiple national organizations there. Controlled by a government.
And any of those will be deemed as valid, so if you go to https://www.torproject.org/download/ and it's signed by a Chinese CA for some reason, to your browser that's perfectly fine.
> What are the chances the official site AND the archive were both compromised?
You're talking about a piece of software that's designed to hide stuff from state level actors. If you're in actual need of such a thing, that threat is pretty damn serious.
I agree with you here, unless you've vetted that GPG public key very well .... it is indeed no better than trusting the CA.
In a way, having JavaScript client-side verification of files as an option would be as secure (if not more secure) in most circumstances because it'd be more noob friendly. At the very least to ensure mirrors aren't doing anything nefarious.
You download the Tor Browser key from a key server such as openpgp, and verify that the fingerprint is the same as that published in the Tor Browser as well as other websites. You can check who has signed that key also.
Once you verify the fingerprint, you import the key into your keyring and sign the key. It’s TOFU, so it’s done only once.
TOFU isn't the proper usage model for GPG, especially not for anything of actual importance.
GPG was made to be a self-contained system. It works based on chains of signatures (web of trust). The GPG program enforces this model, you must sign keys for a signature to be identified as valid. Approximations like "I can find the same key on this other website" aren't part of the intended model.
Key servers don't provide trust, they provide convenience. You may obtain keys from keyservers, but to actually trust a key you're supposed to do the work of verifying it. Eg, if you get my key from a keyserver the only legitimate reasons to trust it is that either you met me personally and compared fingerprints, or you trust somebody else who did that.
The technology of gpg isn't the problem, it's the CLI and non-CLI UX that's the problem.
Mailvelope makes it sort-of easier, but it also fails at UX because it doesn't support clear signatures. Gmail and such should address this. Proton is an improvement but it doesn't allow using an external GPG key. keybase sort-of solved the scalability of effort problem / barrier that is web of trust, countersigning keys, and the bad UX of keyservers.
There is no readily suitable admixture of keybase, Mailvelope, and Proton that doesn't suck while supporting maximum flexibility.
The tech is old and out of sync with modern cryptographic principles. It supports a bunch of obsolete algorithms for backwards compatibility, some of which are badly broken. It has a complicated packet format that's hard to parse and itself has security issues. It encourages bad practices like keeping ancient keys around because they have signatures on them.
It's also highly hostile to using it in any way but how it was designed. For ages, there was no library to parse OpenPGP packets. You had to run gpg itself, maybe give it a fake home directory, feed it whatever you need, parse the output... it's an enormous amount of pain even for simple things, and it's all terribly slow.
And it badly damaged the ecosystem, because either you spend lots and lots of time on reimplementing lots of crypto (which tends to be a bad idea), or you try to trick GPG into doing what you need and end up with a system that's dreadfully slow and painful to use.
The problems you speak of are probably due to this. There wasn't an usable base to build services on until very recently, when GPG was already effectively dead.
Being uncharitable with security critical software is the right attitude to have.
> GPG works.
Yeah, not quite. I've used it extensively. I've got an excellently well connected key. I've tried writing software that uses gpg. I've reached the conclusion that it's a lost cause.
> If you don't like it, invent something better.
People have. Things like the Signal protocol for instance.
Pgp is alive and well on the dark web and the kids with a brain are going to be just fine. You are right though, for the idiot masses "the powers that be" were successful in killing it off.
They HATE encryption, it's why control of the Bitcoin GitHub repo is so critical, an encrypted peer to peer payment option is even more dangerous than encrypted peer to peer communication.
Makes sense to me, it was never super usable. The Windows versions in the early 2000s were ok enough (PGPWin by Symantec?) but outside of that, it was by CLI lovers for CLI lovers which is fine but this could only have worked with massive adoption driving network effects. Not to even mention keysigning parties, that were just the nerdiest thing ever :)
The "security officer" at one of my past roles, had never used PGP/GPG ever. But then again he would send credentials and SSL certs/keys (without passwords), in plain text over emails by replying to all, even when including third parties.
People just have too much trust, are too lazy, or were just giving a job for whatever reason.
I don't understand how the attack works. Does the workflow for enabling, or changing, Facebook email PGP keys not include an email verification step? Or is that being circumvented in some way?
It's just a DoS attack. If valid PGP pubkey is added to account, the account recovery email becomes useless because it's encrypted gibberish that cannot be deciphered unless you have PGP private key.
Not sure, I don't use Facebook. I suppose that if you have access to the account and are able to associate PGP, you might as well change the recovery email address too if hacker doesn't already have a way to read it.
A new key can (should) be activated only if a user can confirm that they can read messages encrypted with this key sent to a configured account recovery email.
Feels like killing a feature for the sake of an edge-case. What's the prevalence of malignant entities taking over a Facebook account (of all accounts you can nick) via PGP takeover?
Facebook account takeovers are really elaborate and very common. Since this is a very easy way to essentially block users from recovering their own account, I can see why they're killing this vector. The account was not taken over through the feature, but the feature made self-service recovery near impossible.
Problem was, it didn't work properly. I tried to use it, but if you had it enabled they would send you HTML markup designated as plaintext, making it unreadable.
> Some Facebook users have also reported instances of hackers taking advantage of the PGP encryption feature to compromise accounts. Once a hacker gains access to a Facebook account, they can proceed to activate email encryption.
It's quite disingenuous to make it sound like PGP was the problem here.
Read that sentence again: "Once a hacker gains access to a Facebook account" regardless of PGP or not... then, of course, they own the account and can do what they want!! But that's the problem, not that they can enable PGP encryption. If you had PGP encryption to start with, ironically you wouldn't be "susceptible" at all as it's the hacker who wouldn't be able to read your emails even after compromising your account (though they may do worse thing at that point).
You may have still been susceptible because it seems that you can just change the key to a new one in that settings screen. I just tried, and setting a new key only asked me to confirm the password. An encrypted confirmation mail is apparently only sent when you enable the feature itself. So an attacker could potentially just replace your key with their own.
Of course they could've just fixed that instead of sunsetting encryption entirely, but note that Facebook didn't say this was the reason why they're killing the feature, that's just speculation from the news article. Facebook didn't give an official reason, so maybe it's really just because of low adoption.
But how are they getting into the account to begin with? Enabling PGP would prevent at least one method of password reset and they wouldn't get as far as the settings screen.
You could make the same case against 2FA. Most sites don't require email verification when you enable it. Someone with your password could lock you out by adding a TOTP app. But I wouldn't consider that a vulnerability. It is, if anything, a consequence of not locking down the account in the first place.
This isn't about sending e-mail through Facebook (although that may be possible, too, I don't know), it's about the e-mails Facebook sends to users, such as password recovery messages.
> This renders recovery emails sent to the user’s email address unreadable, as only the hacker has the encryption keys.
So: PGP encrypted emails were rarely used, except to lock out the legit user after account was compromised.