GPG-Tui, a Terminal User Interface for GnuPG(orhun.dev)
orhun.dev
GPG-Tui, a Terminal User Interface for GnuPG
https://orhun.dev/blog/introducing-gpg-tui/
100 comments
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.
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.
As pointed out elsewhere in these threads there are now much better alternatives available. It’s time for PGP to retire.
What are these better tools?
None of these are alternatives to PGP. There is nothing that comes functionally close to replacing it.
The current wisdom is to have specific tools/constructions for specific purposes, so as to eliminate/reduce footguns and to incorporate modern cryptography.
Edit: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
Edit: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
Current wisdom != a single blog post.
I disagree with every single one of his points btw and from the looks of it, so do a lot of others.
I disagree with every single one of his points btw and from the looks of it, so do a lot of others.
It's not just him.
With tour logic , Keurig exists so get rid of teapots? No thanks.
No need to get rid of good tools, such as teapots.
But PGP is simply not a good tool.
But PGP is simply not a good tool.
gpg --help
The poor UX behind gpg dissuaded me (and likely many others) from using it. Love the tree layout that's used here... time to get back into gpg.
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.
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:
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.
gpg -c secretfile.zip
gpg secretfile.zip.gpg
openssl enc -aes256 -in secretfile.zip -out secretfile.zip.enc
openssl enc -d -aes256 -in secretfile.zip.enc -out secretfile.zip
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.
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.
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.)
// This has been done with other similar apps in the past.
Such as?
Such as?
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)
The problem with this is it's only as secure as the password, and most people choose weak passwords.
Edit: Another is you need to manually enable the checkmark to 'encrypt file names'. Otherwise all file names are in the clear.
Edit: Another is you need to manually enable the checkmark to 'encrypt file names'. Otherwise all file names are in the clear.
The thing where you have to deal with raw keys? For non-technical people?
* https://articles.59.ca/doku.php?id=pgpfan:agevspgp
* https://articles.59.ca/doku.php?id=pgpfan:agevspgp
TLDR at the bottom.
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.
[1] https://github.com/magic-wormhole/magic-wormhole/
[2] https://github.com/psanford/wormhole-william/
[3] https://github.com/Jacalz/wormhole-gui/
[4] https://github.com/psanford/wormhole-william-mobile/
TLDR: ask them to install [5] and [6].
[5] https://github.com/Jacalz/wormhole-gui/releases/
(click on 'Assets' under 'Latest release' and download the zip or tar.gz for your OS)
[6] https://play.google.com/store/apps/details?id=io.sanford.wor...
Try it, it's usage is cute and really feels like magic.
. .
Edit: Discussion from few days ago. The creator is in the comments.
https://news.ycombinator.com/item?id=27262193
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.
[1] https://github.com/magic-wormhole/magic-wormhole/
[2] https://github.com/psanford/wormhole-william/
[3] https://github.com/Jacalz/wormhole-gui/
[4] https://github.com/psanford/wormhole-william-mobile/
TLDR: ask them to install [5] and [6].
[5] https://github.com/Jacalz/wormhole-gui/releases/
(click on 'Assets' under 'Latest release' and download the zip or tar.gz for your OS)
[6] https://play.google.com/store/apps/details?id=io.sanford.wor...
Try it, it's usage is cute and really feels like magic.
. .
Edit: Discussion from few days ago. The creator is in the comments.
https://news.ycombinator.com/item?id=27262193
Signal (on desktop or smartphone) or https://webwormhole.io/
For webwormhole.io, it's server is a weak spot:
https://news.ycombinator.com/item?id=23024833
https://news.ycombinator.com/item?id=23024833
Good point.
Signal
You can use gpg with emails without having to deal with keys and stuff: use deltachat (https://delta.chat/en/)
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.
What specific tasks have you found difficult?
What specific tasks have you found difficult?
[deleted]
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.
gpg has had a --recipient-file option for a while now... no need to import it.
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.
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.
Which is why age has gone nowhere, and pretty much everyone keeps using PGP.
I can't believe it took this long to bring a good TUI to GPG after all of these years. Well done.
Wow, excellent work. Love how much effort has gone into the readme.
There was definitely a gap here and you filled it :)
There was definitely a gap here and you filled it :)
Eh. Still think we need a decent GUI version that integrates with things seamlessly. Like a password manager does.
It's virtually seamless now that it's native in Thunderbird.
I never had an issue using Engimail but so nice it’s native - though haven’t tried it out myself (note to self, go have a play !).
They did have this issue recently (ouch)
https://www.theregister.com/2021/05/24/mozilla_thunderbird_o...
They did have this issue recently (ouch)
https://www.theregister.com/2021/05/24/mozilla_thunderbird_o...
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.
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.
More here: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
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.
More here: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
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.
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.
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.
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.
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 [email protected] 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).
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 [email protected] 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).
I'm not really sure what you're trying to say.
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.
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.
>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.
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.
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.
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.
[...]
> 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.
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.
> these things still do not seem to get adopted
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.
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.
> 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.
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.
Is there a way to do forward security in a non-interactive protocol (which seems necessary, if you want to communicate over email?)
I guess users could publish partial key exchanges out of band?
I guess users could publish partial key exchanges out of band?
Don't use encrypted email. Encrypted email is deeply problematic, for many reasons having little to do with PGP.
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
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."
"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."
Thanks, interesting read.
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.
> 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?
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?
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.
What do they use instead?
Standard replacements:
For signing: signify/minisign
For encryption: age
For file transfer: magic wormhole
For encrypted messaging: Signal (or your choice of e2e encrypted messaging platform)
For signing: signify/minisign
For encryption: age
For file transfer: magic wormhole
For encrypted messaging: Signal (or your choice of e2e encrypted messaging platform)
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.
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.
I wouldn’t hastily recommend unproven tools in the area security.
Here is an example of a cool tool with modern cryptography, forward secret etc, often recommended in HN as an alternative to Wormhole:
https://redrocket.club/posts/croc/
It turned out that plaintext could easily be recovered! One mistake and 100% broken.
There are benefits to an industry standard protocol.
Here is an example of a cool tool with modern cryptography, forward secret etc, often recommended in HN as an alternative to Wormhole:
https://redrocket.club/posts/croc/
It turned out that plaintext could easily be recovered! One mistake and 100% broken.
There are benefits to an industry standard protocol.
croc wasn't recommended by people on HN who knew something about cryptography, and they actually warned against it.
They recommended Brian Warner's magic-wormhole, Signal, Tarsnap, age, Signify, Minisign, libsodium.
They recommended Brian Warner's magic-wormhole, Signal, Tarsnap, age, Signify, Minisign, libsodium.
Signify and Age are not unproven.
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.
Enabling 'disappearing messages' will help I think.
In that case I would recommend Age. It’s a modern and sound replacement for GPG.
https://age-encryption.org/
https://age-encryption.org/
Not really. My opinion in some detail:
* https://articles.59.ca/doku.php?id=pgpfan:agevspgp
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.
* https://articles.59.ca/doku.php?id=pgpfan:agevspgp
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.
For encrypted backups, I believe that Restic is a better tool https://restic.net/
Don’t forget, keys.pub for signing, encrypted messaging, and has wormhole in it
Age is not even close to being some sort of GPG replacement:
* https://articles.59.ca/doku.php?id=pgpfan:agevspgp
* https://articles.59.ca/doku.php?id=pgpfan:agevspgp
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].
[1]: https://github.com/FiloSottile/age/issues/137
[2]: https://github.com/FiloSottile/age/pull/132
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].
[1]: https://github.com/FiloSottile/age/issues/137
[2]: https://github.com/FiloSottile/age/pull/132
I am not sure how PAR2 helps here if your encryption utility refuses to return any data in the first place.
I was responding to a comment that said that age was a "standard replacement" for GPG.
I was responding to a comment that said that age was a "standard replacement" for GPG.
Signal is centralized and in no way can replace emails.
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.
Recommending signal fails to realize that it can be compromised in many ways precisely because it is centralized. A false sense of security.
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?
How would signal be compromised that email could not and which signal is not better prepared for?
> Email clients and server instances are just as centralized in practice.
I don't follow. Not everyone uses Gmail or the big email providers.
I don't follow. Not everyone uses Gmail or the big email providers.
If anyone on the communication thread uses GMail or the other big providers then the entire conversation is subject to the weaknesses of the protocol.
Right now that sits at about a 1 in 5 chance for Gmail alone.
Right now that sits at about a 1 in 5 chance for Gmail alone.
This should have been based on Sequoia instead of GPGME.
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 ?