My interface to gpg is just to append .gpg to a file extension in Emacs that is all, the rest is handled automatically: it will ask for passphrase/present keys, etc.
It’s straightforward to use GPG via command line. I don’t find its CLI more complex than, say, SSH’s.
I use it daily (with secret keys on a hardware key) for passwords, back up, file encryption, some email (admittedly most recipients don’t use encryption), software verification etc.
Newer tools are simpler, but GPG is also workable.
For me the problem is that I use ssh way more often, so it’s easier to remember all the commands. I need to encrypt/decrypt something with GPG only a few times a year, and every time I struggle remembering the commands to do so.
provides an one line description of necessary commands. And ecrypt/decrypt is just `gpg --encrypt/decrypt`. You don't even have to specify an output file. Encrypt automatically creates a new file and decrypt outputs result in console so to put it new file a redirection is enough.
The current wisdom is to have specific tools/constructions for specific purposes, so as to eliminate/reduce footguns and to incorporate modern cryptography.
I get requests from non-technical people in my life for how they can email sensitive files (to other non-technical users) in a way that is especially secure. My refrain: “Technically there is, but… (contemplates PGP for half a second)… it’s very complicated to setup.”
Between email phishing attacks, Dropbox and everyone else on HIBP, I honestly don’t know what advice to give non-technical users besides put it on a USB drive and drop it off. I can think of security pitfalls with literally any other file transmission technology that is easily accessible to non-technical users. If anyone has a suggestion I’m all ears.
In the situation where you want to distribute a sensitive file without a trusted third party of any kind of key infrastructure in place, it's probably easier to not bother with public key encryption. Which isn't too bad:
gpg -c secretfile.zip
Not sure it can get much easier? To decrypt:
gpg secretfile.zip.gpg
The point is that gpg is a tool that most people either already have or can install in a trusted way without downloading binaries from public web pages. Even more common to have installed is openssl:
Using these tools are perfectly secure for all practical attacks. The hard part is transmitting the password over a secure channel.
Public key encryption is even more useful, but requires a little more knowledge on the end user's part on key pairs, signing keys, publishing them etc. Should an end user just wish to transmit an encrypted file then symmetric encryption is easier to understand.
Never use the OpenSSL CLI to encrypt things. It creates unauthenticated ciphertext. It is anything but "perfectly secure".
I don't think it's even the case that the OpenSSL project wants you to be using their code this way. It's just that Unix nerds (hey: it me) find things like this and adopt them, then write things about how they're "perfectly secure" in message board slapfights. It's a microcosm of the whole problem.
Given the use case here, where someone wants to send a single file to someone else, with no pre-existing way to communicate securely, why would it matter? The only practical attacks would be on the passphrase itself (which they have no way of protecting). The fact that openssl accepts any passphrase is likely a bigger problem in practice than the lack of authentication.
If you want to send something securely, I’m not sure email is the best method. Even if you understand all the risks and pitfalls and side-step the minefields it’s still insecure in non-fixable ways. ProtonMail make a service out if it mitigating those issues as best they can (but even they explain their threat-model and what they DON’T mitigate. Others such as Silent Circle ended up giving up.
You could recommend to those non-technical people to either:
- Use Signal
- Sign up to two free ProtonMail accounts and use those to exchange with one another. That way they’re both e2e and don’t leave the eco-system. And no setting up of PGP keys and such like, and a nice web UI.
If they’re non-technical I wouldn’t suggest PGP IMHO. It’s actually easier to setup S/MIME for non-technical people (I’ve had some success there myself).
Of course part of this is that no one has solved the UX and usability and that it never reached mainstream in most ‘typical’ email clients. To set it all up you have to be fairly technical. When it should just work out of the box - like Signal.
Signal is not secure if you're concerned about the App Store maintainer or Signal themselves having access to your data (you can't know what the contents of the app on the app store are and it my exfiltrate keys. This has been done with other similar apps in the past.)
7zip encrypted archives, the "create protected archive" should be accessible with right click on most platforms (I use the CLI version and I only have a vague memory about the UI)
It seems the answer is Brian Warner's magic-wormhole. You're gonna see lots of file transfer sites with wormhole in their name, but if you want security you should use the original one, which is BW's m-w.
It is implemented in Python [1], so it's hard to install.
So someone made a Go version of it [2] that has binaries for windows, Mac, Linux, BSD etc. But it's command line so maybe not suitable for lay people.
So another person made a GUI for it that also has binaries for all OS [3].
Also there is an android app [4]. Someone needs to implement an iOS one.
I really don't get this attitude, though I think it must be valid, since I seem to be almost alone in disagreement. I use plain old GPG for a lot of purposes, and I don't find its command-line usage difficult at all. Key management, encryption, decryption, signing — all of these operations are pretty straightforward.
It's very hard to simply encrypt a file to a given pubkey (due to the key trust model) compared to, for example, something like age (where it's just `age -r $PUBKEY`). You also have to set GNUPGHOME somewhere and import the key first, you can't easily do it statelessly without tracking mud into the filesystem first.
I agree that age is a huge improvement over PGP, and the rightful heir to its throne.
However most people complaining about PGP's UI go on to explain that this is why you should use Telegram or WhatsApp. That line of reasoning is just bogus.
Huge improvement? It doesn't even come close. It's yet another half-assed reimplementation of the easiest PGP features to reimplement. There is no web of trust, no smartcard support, not even signing.
Which is why age has gone nowhere, and pretty much everyone keeps using PGP.
Virtually seamless in things such as Protonmail or Thunderbird. It gets more complex if you want to use hardware key storage, as one should with GPG. The setup is 90% of the pain, awful defaults, terribly discoverable documentation.
While this is awesome work, it seems pointless since the protocol and ecosystem around it is so hopelessly convoluted, misunderstood, and in a varying state of abandonment. All my friends in the security steer well clear of it.
If you approach it from "run these commands to do these things" it's not bad. Most wrappers are wrappers around a very limited set of functionality.
It sticks around because it has some interface that users can use and is scriptable. Everyone saying GPG is bad usually has no general solution to replacing it.
The best-known problem with PGP is its poor usability, but that's not its biggest problem. It's biggest problem is an archaic design that literally predates much of modern cryptography; most egregiously, PGP is almost never forward-secret, and almost always relies on long-term keys, which is a deadly combination.
A more fundamental design issue is simply that cryptography engineers long ago abandoned the idea of a single toolset or even a single standard design that handles multiple problems. Messaging cryptography is not the same as backup cryptography, which in turn isn't the same as secure transports, or package update security.
I don't think people want forward secrecy for their email. If they get a new computer, they probably want all their mail on there, right? Isn't porting over their email efficiently at odds with forward secrecy? Also, is forward secrecy compatible with any kind of encrypted search (I know most encrypted search schemes leak too much these days, but if the alternative is not encrypting email at all...)?
Also, how would it work with multiple people in a thread that can be added/removed arbitrarily, or email addresses that resolve to multiple users? Messaging and email seem like different models to begin with.
Keeping old messages around for all practical purposes negates forward secrecy in any messaging system. It isn't just an email issue. If they can get your secret key they can pretty much for sure get your old messages.
Most email users keep their messages in cloud storage (IMAP) so that changing computers is a non-issue. OpenPGP is an encrypt once scheme so that messages on an IMAP server are encrypted and stay encrypted.
Systems that lack forward secrecy are by design incapable of preventing archives of eventually-plaintext messages. There's nothing you can do about it; every message you send is irrevocably a part of the adversary's record, and, because you rely on a single long-term key, you know eventually that record will be plaintext. That's why forward secrecy is such a big deal, and why every modern messaging cryptosystem uses ephemeral keys.
But this only applies for messages that are deleted on your local device (either manually or through an automatic timer). Otherwise, whatever adversary stole your keys can steal your message archive too, they're on the same device. Now, assuming you aren't going to be deleting most of your mail, I don't see how forward secrecy is "such a big deal" in this scenario. It's certainly nice to have, but it definitely has drawbacks wrt the features I mentioned earlier.
Post-compromise security, on the other hand, makes more sense, since the future messages don't exist yet.
You can't meaningfully delete messages in non-forward-secret systems, because part of the premise of all these systems is that your adversary is recording everything.
I agree with you there. But is your point that any secure email system must critically have forward secrecy, or its insecure? Even though forward secrecy really only gives you any benefit for the messages that you delete, which most people don't in the context of email?
Just thinking, if people had the option between 1) deleting their mail and 2) email search, secure (unlike WhatsApp) and easy (unlike Signal) backups, ability to offload your email archive to the server (it's common to have gigabytes of mail, do you want to store all of it on a mobile phone forever? what happens if you drop it in a river?), and so on, don't you think people would go for option 2?
This is all disregarding the specifics of PGP-encrypted mail, for which I agree is not great.
The point is that one of the basic properties of messaging encryption is forward secrecy. It's an argument about how messaging is different from backup, package signing, file encryption, distributed logs, file transfer, and secure transports (though some of these really want forward secrecy too), and how PGP advocates back-rationalize not needing forward secrecy so they can defend their weird archaic tool.
Your argument is that forward secrecy is important in messaging because forward secrecy is important in messaging?
I'm not trying to be argumentative here, I actually don't understand what the reason it's so critical is, nor have I really found any explanations online. For text messaging where you don't really go back to read your old messages, sure, forward secrecy makes sense. Email seems to be a different story where user expectation is different and forward secrecy both precludes many desired features and also doesn't provide significantly more security, other than in very limited circumstances.
Also, I'm not an advocate of PGP at all. If people can use Signal for their usecase, great! They should do that. But Signal's model does not work for everyone's usecases. How do I send a Signal message to security@example.com to report a vulnerability? Is the entire security team supposed to share a mobile phone with Signal on it? What about banks that need to send secure email to each other, but must retain all messages for compliance purposes? (Again, I'm not advocating that PGP should be used in this scenario either, just that there's room for a better solution here, possibly without forward secrecy by default).
The premise of cryptographically secure messaging is that you have an adversary recording all your message traffic.
Lack of forward secrecy implies, logically, that if your long-term secret is ever compromised, every message you've ever sent is recoverable from the adversary's archive.
The point of forward secrecy is to break that attack, so that your adversary needs your long-term secret at the time it was used to send a message; having it after the fact doesn't help.
I'm sometimes in the mood to write long posts and comments explaining this stuff, but today, on the bottom of this old thread, if you're trying to make a point about PGP vs. Signal and don't know how forward secrecy works, I'm probably the wrong person to have this conversation with.
>The premise of cryptographically secure messaging is that you have an adversary recording all your message traffic.
Agreed.
>Lack of forward secrecy implies, logically, that if your long-term secret is ever compromised, every message you've ever sent is recoverable from the adversary's archive.
Also agreed. I am trying to say that this only gives you better security for messages that you have deleted on your device, because if you haven't, regardless of whether your protocol is forward-secret or not, the adversary that has the power to compromise your device will get access to the message the plaintext of which is on the device, even if the keys aren't. Thus, the scope is significantly limited, unless you have a policy to regularly delete old messages on your device, and most people do not want this for email.
I can assure you I understand the cryptographic properties of forward secrecy. I don't understand your claim that it is a strict requirement for every secure messaging system, including an email-like usecase.
>I'm sometimes in the mood to write long posts and comments explaining this stuff, but today, on the bottom of this old thread, if you're trying to make a point about PGP vs. Signal...
I already said several times I don't care about PGP. I feel like you're not really reading or responding to any of my arguments about why forward secrecy doesn't really help you much in most users' threat models or why it precludes various desirable features (of course, I could be wrong here, which is what I'm asking about). Thanks for your time anyway.
Again: without forward secrecy, you can't delete old messages, because your adversary has already recorded them. The point is that a lack of forward secrecy creates a subtle limit to the security that can be achieved.
Yes, that's exactly what we both agreed on 6 comments ago. The question is, is the ability to delete messages critical enough to require in any possible secure messaging solution, at the expense of features like email search, archiving, backup, and transfer-to-new-device?
>Systems that lack forward secrecy are by design incapable of preventing archives of eventually-plaintext messages.
That is not what is being claimed here. Unless you add extra security in the form of something like a strong unique passphrase for the archived messages then an attack that gets the private key also gets the archived messages. In general, if you have a more secure method for protecting the archived messages you could of used it to protect the private key. It is effectively the same problem.
Adding to that, is there a forward secrecy solution to email? I believe this happens in TLS during negotiation, but a similar thing doesn't really exist in one-way communications.
Assuming you don't want to keep any "chain state" in between messages (which seems reasonable), you can always consume a fresh one-time key of the recipient for every message. The first downside is how you know that the one-time key hasn't been reused, for this you can either trust the service provider or use blockchain or blockchain-like technologies. Second downside is that the user has to be online to generate a ton of one-time keys. I believe puncturable encryption helps with this so the recipient can "puncture" their key at the used-up key identifiers, and thus doesn't have to be online all the time. No idea how practical this is.
What's your opinion on recent sequoia implementation? I've heard your arguments numerous times and was quite convinced, but that project and their offsprings (openpgp-ca, hagrid, ..) and other stuff like wkd seem to drag the ecosystem to something nicer. I consider it promising.
I think things written in Rust are better than things written in C. I think modern AEAD cryptography is better than the 90s cryptography that GPG uses. I think the PGP installed base mires the whole ecosystem in C code that accidentally goes quadratic just trying to parse keys, no matter what happens with Sequoia. It's a good project --- this TUI is probably a good project too --- but in a doomed ecosystem.
I am aware of these arguments. Still, GPG exists, and no one has really proposed good solutions, or at least the solutions that have been proposed are not taking off for some reason.
It is true that pointing out a problem does not need to be accompanied by a solution to be valid, but at this point, if you're going to complain please work towards solving the issue. It is too easy in this case to come off as someone who "knows things" while gesticulating at GPG in a derogatory manner while still accomplishing nothing.
> GPG exists, and no one has really proposed good solutions
[...]
> if you're going to complain please work towards solving the issue
Perhaps because you are asking the wrong question: "PGP/GPG is old, broken, and insecure, what is an exact drop-in replacement that I can substitute for it?"
Instead, the question should be: "PGP/GPG is old, broken, and insecure, what is a replacement for [this specific thing I am trying to accomplish with it]?:
So what are you trying to do with GPG? Sign a package? Encrypt a file? Store a backup? Transfer a file? Send a message? There are plenty of modern, secure solutions for these.
I know. I am aware of the appropriate questions and some (most) of their answers. But these things still do not seem to get adopted. Best I've seen is a few projects pick up signify. Signal is OK I guess, but still does not solve a lot of things a decentralized system can.
People always join these conversations to namedrop projects to sound smart and security conscious, apparently not having tried to integrate them into their existing workflows.
If I understand your comment correctly, the reason you are using an old, insecure, and broken tool is because the secure replacement is not as widely used?
Are you looking for some specific percentage of the population to adopt it? What is that threshold?
> Signal is OK I guess, but still does not solve a lot of things a decentralized system can.
Serious question: what problem does a decentralized tool that old, insecure, and broken solve that you would use it instead of one that is secure but "centralized"?
> People always join these conversations to namedrop projects to sound smart and security conscious
I can't judge other people's motivation for mentioning PGP/GPG alternatives, but the projects they mention certainly fit the criteria for being secure replacements. Are you going to disregard their answers because you have deemed their motivations unfit?
> apparently not having tried to integrate them into their existing workflows.
If you could explain your specific PGP/GPG workflow, perhaps someone might be able to suggest something to replace it.
> Bunch of straw questions, I don't care to answer them. Answer your own pointless questions.
By "straw question", you are implying that I replaced your argument with a false one.
In the upstream comments, you agreed that PGP/GPG is broken and insecure. We have no difference of opinion there. You then stated that the reason you still continue to use it is because a) the alternatives are not getting adopted and b) are not decentralized. You also c) questioned the motives of people suggesting the alternatives, and d) stated that they have not used them in existing workflows.
All of these are things _you_ stated, I was careful to quote each point you made as I responded to them.
If I misstated your position or replaced it with a straw man, feel free to point out where I did that and I'll gladly correct myself.
Signal/WhatsApp/etc certainly seem to be taking off, and they seem to cover a broad swath of the use cases in messaging that people have historically tried to use GPG for.
It's always funny to see people talk about how important it is that PGP has an installed base and then think about how many PGP users there are compared to Signal Protocol users.
> The best-known problem with PGP is its poor usability, but that's not its biggest problem.
I don't know - if the design were more sounds from a crypto perspective, but it was still as easy to fuck up as the current interface, would it really be better?
This reminds me of my father's advice to every client (he had a corporate litigation practice):
"When you feel the urge to write an email, pick up the f*king phone instead. When in 5 years you're being cross-examined you can say 'I don't remember saying that' and you won't be lying, because we're too old to remember things, and I won't have to bill you for the time it takes to read all the f*king emails."
It's scriptable, but scripting GPG is full of footguns. You generally want to do everything through status-fd to avoid most of the footguns, which is a pain to work with through ordinary shell scripts.
I'm still think that OpenPGP is the best solution for the first two. But the two tools at the top have the same problems as pgp.
How do you trust some key material. The WoT is a complete failure, but modern solutions like WKD are amazing and make PGP just plain work.
The one nice thing about age is the ability to encrypt to a GitHub users key. However, even that is possible with OpenPGP. Here is a tool that I made ~7 years ago that does something similar: https://github.com/georgyo/sshcrypt
Another thing minisign/age don't have is a method to say that a key is compromised.
I don't think the solution to the problems with OpenPGP is too just ignore the problems and switch to using bare keys like new tools are doing.
Signal is an instant messenger ... which is fine, but sometimes you really do need the extra security provided by an offline messaging solution like OpenPGP. The Cellebrite thing was a good example of this. Cellebrite doesn't get OpenPGP messages as they can and are usually protected by a passphrase. Cellebrite gets Signal messages.
Age might be such a replacement some day for just the encryption function. But it has a ways to go. Actually defining the format would be a good first step.
I don't think that's a fair comparison. Age was never meant to fully replace GPG, so complaining about missing features it was never meant to have doesn't make sense.
The only valid criticism is about its handling of corrupted data, but for that too you can use an external tool like PAR2 to generate recovery data. I do this with my GPG backups and other data as well.
I like that age follows the Unix "do one thing well" philosophy, and that I can use other similarly scoped tools for other features. There are still some things I'm missing, but these are slowly being worked on[1,2].
Email is default plaintext, can't force encryption on groups, leaks --- in fact, gleefully publishes --- the most important dragnet surveillance metadata (even when ostensibly encrypted), creates long term archives of secrets, is built on long term secrets, and, to boot, is in the real world itself effectively centralized. It's hard to even imagine a secure messaging system less safe than email. Recommending encrypted email is simply malpractice.
Email clients and server instances are just as centralized in practice. Yet email servers almost always know everything about you in contrast to Signal. And you can prove this by reading their code and by the fact that they respond to subpoenas with as little info as they do.
How would signal be compromised that email could not and which signal is not better prepared for?
I see that sequoia has sq, a command line utility but it says it is stateless which IIUC means that it does not store keys. I would like to use it but not quite sure how. Any recommandation ?
