On a somewhat related note: GnuPG gets plenty of hate from the crypto crowd for being "obsolete" and insecure.
I would humbly propose that before you go telling everyone to stop using gpg, implement something that works, builds, and that doesn't break after 6 months or so. I've been using gpg for what, 20 years now? And recently (as in, three or four years ago) started using it with private keys stored on YubiKeys (using drduh's excellent guide). I also use it for symmetric encryption. It works. It doesn't break. It gets things done, and while I'm not secure from state-sponsored hackers, all this is infinitely better than no encryption.
Rage for example, is not in that category — I added it to my ansible automation as a test, and it broke after several months.
When the crypto crowd complains about PGP being obsolete, they don’t just knock PGP, they very often mention alternatives. One of the most frequent recommendations is instead of using ordinary email and trying to bolt PGP onto it with individual contacts, use an encrypted messenger. I have been using Signal for four years now with the same install moved from phone to phone, and it has worked just fine. I can chat with my friends and relatives with E2E encryption, while I could have never got them to use PGP at all.
That solution won't let me encrypt my backups, I think.
Incidentally, Signal is another example of an impractical solution being pushed without consideration for practical requirements. Signal will LOSE ALL YOUR DATA if your phone (iOS) dies. There is no way to backup your chat history and images. It's been like that for years and we get silly features instead of this fundamental thing.
Yes, I know many people like it this way — you are in the minority, and there should be a configuration switch saying "do not backup my data". Most people do not expect that their entire history will be gone one day. Phones die, phones get stolen, and you expect you'll get your history and photos back when restoring from an (encrypted!) backup. Not so with Signal. So the next time you tell people to use Signal over WhatsApp, don't forget to tell them that Signal will lose everything one day, while WhatsApp will not.
Back to my original point: before anyone knocks "old obsolete" apps, consider carefully if the new shiny thing really does everything that the "old obsolete" app did, is it reliable, maintained, and will it stay around for 10+ years.
> Signal will LOSE ALL YOUR DATA if your phone (iOS) dies
I'm seeing this often on HN.
While it's a pain, it is not impractical. Most people don't care about this. They don't come back in time in the conversations.
If you really care about this. Like, you care that much. Just pair Signal Desktop and make a regular backup of your profile. All your messages and attachments are there. If your Signal ever gets borked, you can always put your machine offline and open Signal-Desktop on this backed-up folder. You can also open the db with sqlcipher and access all you data with it, the scheme is not too complicated to grasp.
Ask me how I know.
And since Signal is open source, you can always read its code in case of doubt. Someone could build a convenient UI to display or export the messages and attachments in a user-friendly format. This can happen after the backup is done and Signal breaks.
All this said, people may expect privacy when using Signal, so make sure your backups are well protected. This is the hard part, actually.
I think you are confirming my point. "without consideration for practical requirements"
I can tell you that my daughter cared about this. She cried for a long time when her phone just suddenly died (while charging, no reason, total loss) and her Signal history wasn't restored. I couldn't explain why Signal was the only app that didn't get backed up.
I can tell you that my friend's parents cared about this. The photos of their grandkids were suddenly gone. My fried couldn't explain the reason for this, all the other data did get backed up.
And sure, between us geeks we will keep saying "well ACTUALLY they SHOULD HAVE kept the photos elsewhere", and we'll say "this is good because it makes us more secure" and we'll say "most people don't care about this". We'll all "well actually" ourselves, while patting ourselves on the backs.
> I think you are confirming my point. "without consideration for practical requirements"
I don't think I am. A practical answer is: "Install Signal Desktop".
And I still think we are few who care about chat history. I'm sure there are people who care. I'm such a person.
It's also only a missing feature for iOS user, so that makes it: "of the few people who care about chat history, the minority of people who use iOS are only covered by installing Signal Desktop". A pain for these users, but they have at least two workable solutions. Using Android or installing Signal Desktop somewhere. (yes, caveat, you need to do that before losing your phone)
By yes, I agree that it would be better to have the backup feature.
> I don't think I am. A practical answer is: "Install Signal Desktop".
IMHO this is not always practical. Signal Desktop can easily get out of sync if you change versions and the only proper way to fix it is to clear all the local data, including your chat/contact database. AFAIK, the only source of truth is your phone.
> A pain for these users, but they have at least two workable solutions. Using Android or installing Signal Desktop somewhere. (yes, caveat, you need to do that before losing your phone)
"These users" don't even have a desktop computer :-)
"These users" will just use WhatsApp. It works it doesn't lose data, and everyone around them uses it anyway.
"There's a technical issue with email encryption, but we have a solution: don't use email! instead, use this different protocol, that doesn't work with email clients or email addresses, but instead uses a telephone number as an identifier!"
I've never tried Signal, because I don't want my telephone number used as my identifier.
A bug in email encryption can be fixed by fixing the bug; proposing a completely different protocol/application isn't fixing that bug, it's just saying that this other protocol/application doesn't have the same bug. It's not a solution; at least, not for me.
It's a pity, but email never was designed for security, and you can't graft it on.
GPG doesn't really do much for security, because a lot can be told from simply who communicates with who and when, and GPG does absolutely nothing there.
The biggest bug in email encryption is that important message data & metadata can't be encrypted for SMTP to work. It's a bug in email, and there's no backwards compatible fix.
This is like asking how to drive across the ocean and getting mad when someone tells you that you need to take a boat.
Email just fundamentally isn't encryptable; the protocol and the way it actually works in practice (hi, antispam!) requires that important parts of the email not be encrypted, and things like asynchronous communication make it difficult to do encryption to the gold standard of quality. Also, turning on encrypted email also disables several email features from the perspective of the user (hope you didn't want to search your emails!). The end result is that email encryption is, as someone else put it, LARPing rather than security.
There are a few very narrow use cases for which encrypted email may make sense (largely in cases where you're not concerned about hiding the existence of communication channels, just message contents, and you can do out-of-band public key communication). But notice that those use cases don't include "I want to message someone else securely," and it's definitely not someone that would work if you tried to let regular users do it.
None of this explains why I need to give you my telephone number to get on your boat.
Identity is the core of the matter and that is invariant of the modes of transport. On top of that comes key management. On top of that you can build your secure application on whatever platform.
Total end to end encryption can only be built on top of identity and never (ever) on a specific channel. And TE2E should be the social goal.
Even to the extent that's true (and a lot of it is not), none of that explains why there are absolute zero email replacements, and indeed "security" people seem to promptly display brain damage whenever the idea is brought up. "Email-like" doesn't mean it has to be actual current standard email, there could be an "xmail" that has a UX near exactly like email but is more modern. But instant messengers (let alone centralized ones) are not a replacement for email and never will be, and the stubborn idiotic insistence they are is as surprising as it is infuriating. If you insist it's security or email, the answer is email, and that's how very important information will continue to be sent.
Although that said, and while not disagreeing about its flaws, I still can't let entirely go by:
>the protocol and the way it actually works in practice (hi, antispam!)
But anti-spam works fine with encrypted email (putting aside practicalities of no forging making spam harder anyway).
>asynchronous communication make it difficult to do encryption to the gold standard of quality
Nobody gives a shit. Asynchronous communication is well worth it.
>hope you didn't want to search your emails!
lol wut? If I go into Mail and searching something it can include encrypted emails the same as whatever else, why wouldn't it?
There are, obviously, replacements for email. Most of us get a tiny fraction of the email we did just 10 years ago because so much has moved out of email and into other messaging systems. The faulty logic being used here is that there is nothing shaped precisely like email to replace email, and, of course, there never will be.
At the point where you’re joking about other people having brain worms, I think maybe we need to accept that this thread is no in keeping with the guidelines around comments.
You can read through that if you want, frankly it kind of surprises me how nothing at all has changed since then. It's impossible not to respect Thomas immensely in this field overall, or most of his commentary. Which is why I was and remain genuinely befuddled by his replies on this specific topic. So it goes?
Wire uses the Signal protocol and your e-mail address or a username as your identifier. But you still depend on somebody else's infrastructure. We probably want XMPP with OTR or OMEMO.
> When the crypto crowd complains about PGP being obsolete, they don’t just knock PGP, they very often mention alternatives
Those alternatives have different use cases compared to (open)PGP. So, Moxie said GPG is too complicated? If Signal goes down, how long will it take you to spin up your instance of server and clients, ready for delivery? How much would cost running reliably that infra? For email and GPG, I can get everything in 15-20 minutes, including registering the DNS name, DKIM, and SPF. I can also sign documents, images, and invoices with GPG; in short, I can do business. What can I do with Signal: chat, send nice emojis, and make calls?
Proper security and encryption isn't a toy, and let's not kid ourselves by skinning apps with shiny buttons and cool claims that everything people have done before sucks.
The alternatives are generally far better than email, which is why normal people (and most of us) get so little email these days. My email accounts have more life as a transaction recording system for online shopping than they do for interpersonal communication. Email has largely been superseded. That alarms nerds like us, the way it alarmed people when HTTP superseded purpose-built network protocols, but there is a losing side of this argument, and it's the side that is still using Mutt.
If you are concerned about digital document signing, then that is a different use case from the OP who speaks of encryption and being “[not] safe from state-sponsored hackers”. For digital signing, business sectors like e.g. banking rely on PDF e-signatures[0], not PGP.
"digital signing" in banking sector means something completely different than PGP-like "digital signing". PGP-like digital signatures can be applied on any document and file and you can easily validate the author by their public key and can't be easily forged.
Your post said “documents, images, and invoices” and “business”. In the real world, documents and invoices in business are overwhelmingly sent in PDF format. Even images get embedded in PDFs a lot of the time. PDF e-signatures can be validated, the technology is based on very standard crypto with FOSS implementations. Fine if you have a different workflow that requires PGP, but most people clearly don’t feel it is impossible to “do business” otherwise.
> In the real world, documents and invoices in business are overwhelmingly sent in PDF format
This is evasive and dismissive. When your parent is talking about the issue, there's a good chance he is already using it. Telling him what "the real world" does is irrelevant. He has a use case already, and needs a solution for his use case, not for the rest of the world.
Almost every time on HN that there is a discussion of changes in technology that experts would argue are overall good, there is always someone who says “But that would break my use case!” This even got lampooned at xkcd[0]. OK, I understand that he finds this trend vexing. But no party to this discussion is obliged to spend their time and effort on suggesting a solution, especially when we don’t know his specifics and our suggestion might simply be rejected out of hand.
Except when it comes to GnuPG, you have to realize:
1. Many, many people used it, and continue to do so.
2. The anti GnuPG crowd keeps coming and touting alternatives, and then complain when the people in the prior bullet point out the impracticality of the alternatives for their use case.
We get that GnuPG has issues. We get that sometimes the alternatives are better. We can coexist with them. People simply don't understand that for a number of tasks, GnuPG is totally appropriate, and solves the problem with little pain.
> In the real world, documents and invoices in business are overwhelmingly sent in PDF format
In your real world, probably. In actual real world, people use MS Word/Excel (or LibreOffice) and images a lot, beside PDF. Good luck using e-signatures with that :)
I've been using GPG for about as long, and I've had problems with it.
They've used some cipher, was it IDEA, than then got removed. So then I had to hunt down years old versions in order to be able to extract my old backups.
Or was that more of a PGP than GPG problem, and I misremember?
I don't understand cryptography, and I don't understand the particulars of the concerns that people have with GnuPG. I do know I've used it maybe once, and it wasn't straightforward.
You wrote: "I would humbly propose that before you go telling everyone to stop using gpg, implement something that works, builds, and that doesn't break after 6 months or so."
Keybase did some stuff and got tons of users. It even had a command-line client. It was all open source, too. Is there any reason that the crypto old guard hasn't just shamelessly copied Keybase? The most important being: its CLI (the design, not necessarily the implementation) and the overall "shape" of the project organization/structure. Why hasn't gpg been "uplifted" into a Keybase-shaped "shell" for people to interact with? I.e. at both the tool level and at the collaborative project level?
RMS came from the AI lab working on Lisp machines. Despite this, he recognized that a UNIX-shaped project was the correct vehicle for his vision, given its growing popularity. Why haven't the GPG folks given up on trying force people to do things their traditional way and attached their cart to a horse that has legs?
I would humbly propose that before you go telling everyone to stop using gpg, implement something that works, builds, and that doesn't break after 6 months or so. I've been using gpg for what, 20 years now? And recently (as in, three or four years ago) started using it with private keys stored on YubiKeys (using drduh's excellent guide). I also use it for symmetric encryption. It works. It doesn't break. It gets things done, and while I'm not secure from state-sponsored hackers, all this is infinitely better than no encryption.
Rage for example, is not in that category — I added it to my ansible automation as a test, and it broke after several months.