A Schism in the OpenPGP World
lwn.net
lwn.net
Way back, there was a rambling and expansive process to update the OpenPGP standard. Years. So eventually it was decided to do a more focused "crypto refresh" that would be restricted to just important cryptography concerns. The GnuPG program was part of this. During the process the head of the GnuPG project (Werner Koch) spent a lot of time pushing back against what he considered pointless or wrongheaded changes. Eventually things seemed to stabilize and there seemed to be a consensus and people started paying less attention. Koch was one of those people.
The process then wound up again and a bunch of stuff that Koch opposed ended up in the standards draft. Koch eventually noticed and ended up taking the position that the GnuPG project would not follow the new changes and would instead stay where they were.
I think the very best outcome here would be if the various entities would accept that the process is working to the extent of clearly showing that consensus has not been reached and can't be reached from this point. The process will have to start yet again. The root cause here seems to be that there is no real serious issue with the existing standard, so attempts to update it lack a focus. As a result there is a tendency to try to change everything.
As for lacking focus, I'm obviously biased as one of the authors of the document, but the charter of the crypto refresh [4] was rather narrow, and aimed at modernizing the cryptographic primitives in OpenPGP. That's what the crypto refresh focused on; e.g. see [5].
[1]: https://www.rfc-editor.org/rfc/rfc8789.html
[2]: https://www.rfc-editor.org/rfc/rfc7282.html
[3]: https://mailarchive.ietf.org/arch/msg/openpgp/yz6EnZilyk_90j...
[4]: https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/
> All of those other projects their purpose of existence is to be compatible with GnuPG.
That's not how the IETF process works. Technical arguments are more important than who has the most users.
> If compatibility wasn't a concern you'd just use something new like Age.
That being said, OpenPGP.js and GopenPGP do actually implement the old version of the draft (now dubbed "LibrePGP") as well (and everybody obviously still supports RFC4880), so there's no real risk of incompatibility. We just also implement the crypto refresh, and hope that GnuPG will do so as well, so that everyone can benefit from the improvements made there.
Right, but I assume the point of Proton Mail using OpenPGP is so that mail sent by Proton Mail can actually be verified/decrypted by other systems that aren't Proton Mail? So compatibility with the widely known GnuPG is a goal. Otherwise the question remains, why PGP?
> That's not how the IETF process works
Sure, but it is how the real world works.
> That being said, OpenPGP.js and GopenPGP do actually implement the old version of the draft
So are you doing both? If you implement the crypto refresh and GnuPG doesn't then you lose compatibility, right? If you don't lose compatibility and are somehow doing both, then what's the point?
OpenPGP keys can signal support for various features and algorithms - such as AEAD modes. As one example, the crypto refresh specifies GCM (as optional to implement).
This means that, when sending email between Proton users and OpenPGP implementations that support that, we can use GCM - which has certain security and performance benefits.
If we send email between Proton users and GnuPG, we won't use GCM, so we won't lose compatibility, but users also won't benefit from those (and other) security and performance improvements.
Would it be possible to use different subkeys for each (a good idea in any case, since it would allow revoking them separately in case one of them is leaked)? I don't recall whether the packet with the features and algorithms support information is attached to the key or to the subkey.
There was recently such a discussion on debian, that keys used by protonmail and similar are not allowed to be used for uploads.
My experience with Proton is that they really don't care anything about encryption or signatures except as they apply to emails between Proton users: http://jfloren.net/b/2023/7/7/0
I've addressed the points in the blog post in https://news.ycombinator.com/item?id=36643124.
But yeah, I was more thinking of email than code signing, since it's hard to get statistics on the latter I should've qualified :)
Then, some (backwards-compatible) changes to the OpenPGP standard were proposed, and every implementation implemented them. (These were specified in RFC4880.)
Then, some (backwards-compatible) changes to the OpenPGP standard were proposed, and many implementations implemented them. (They never ended up in an RFC, but are now dubbed "LibrePGP".)
Then, some more (again backwards-compatible) changes were proposed, and many implementations implemented them, but not GnuPG, for now. (This is the crypto refresh. It should become an RFC soon.)
It's a shame GnuPG doesn't want to implement the crypto refresh at this time, but that shouldn't cause incompatibilities (if all implementations are conservative in what they generate). Messages sent between GnuPG and other implementations can still use RFC4880 (the old OpenPGP standard), they just won't benefit from the improvements in the crypto refresh, unfortunately.
Further: I don't think this is intrinsically a bad thing. Other, more successful projects work this way, most notably WireGuard. You have to judge these things on the merits.
Worth noting is that the choice to move on with the rfc process was made very deliberately: there was a large thread on the mailing list to try and find a compromise. In this discussion, Werner Koch's negotiation standpoint basically required things to go 100% his way. The choices for the working group chairs ultimately boiled down to: 1. Closing down the wg with no result. 2. Moving on as a mostly functioning working group, at the cost of leaving Werner/GnuPG in the rough. 3. Reverting everything to the way Werner preferred.
None of those were great options, obviously.
Note that for option 3, the draft that is now LibrePGP and which was edited by Werner until circa 2020, had spectacularly failed to gather support and achieve consensus back then, and effectively stalled the working group for years. The LibrePGP project now claims that this draft was "the last consensus" of the working group, but at that time the reality was that Werner had gotten pretty used to just committing to master of the spec draft whatever he felt like, instead of seeking group consensus.
At the moment there doesn't seem to be a chance for the parties to come to an agreement. I'm curious to see how this develops.
Nothing is worse than open source people not reaching consensus and moving on, because nothing will make the enemy of privacy more happy.
* https://blog.pgpkeys.eu/critique-critique
Which goes over the concerns/critiques that Koch posted at:
You are describing S/MIME?
On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand. Handing a payload of data to a third party that the recipient can eventually query to retrieve makes it much easier to grab a hold of and try to decrypt in the future. The same is true of SSL to an extent, but SSL traffic is much more voluminous, such that saving all of it to eventually crack and decide if there's anything worthwhile in it is unlikely.
The only real way to transfer private data between two users is to do it live with an ephemeral channel, whether that's in-person or via SSL or etc. The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.
[0]: https://en.wikipedia.org/wiki/S/MIME#Obstacles_to_deploying_...
That's a problem with all encryption anyways. Inspection has to be done at the end-user's device. So I don't think it's fair to hold that against S/MIME.
> On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand.
If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.
> The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.
To some extent I agree. An ubiquitous deployment of digital signatures would already solve a bunch of problems and most of the rest are handled by transport encryption.
I don't think that has to be the case, though. Protocol negotiation is a thing; SSL negotiating the version of the protocol to use, HTTP 1.1 -> 2.0 negotiation, etc.
You could imagine a mail protocol that starts at an encryption level, then during the negotiation process when the mail-to-be-delivered provides a public key, the recipient server can check that key against a listing of keys accepted by the user, and if not included, attempt to negotiate down to an unencrypted version of the email.
The sender of the email could choose to not allow that downgrade and get an undeliverable mail error, or they could choose to allow the downgrade to plain text/html email. This could then be run through the standard spam/malware filtering as usual and the spam eliminated, while email that came from already trusted email can skip those filters because the user has already judged them worthy of accepting and keeping the communication private.
So I don't think that's an intrinsic difficulty of all encryption schemes for email, but...
> If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.
So first I'll state that I don't think all E2EE messaging apps reach the following bar, either, but the difference between an ephemeral SSL-encrypted communication channel and an email, fundamentally, is that the ephemeral channel won't be written to a disk somewhere, while the email will.
The window in which it is possible to get a copy, and the difficulty in obtaining it, is much more in favor of secrets staying secret in the ephemeral channel than it is in encrypted email. The data payload persists longer, and is likely encrypted by the same private key across many emails, so getting the emails and getting the keys are much easier than with the ephemeral channel that generates a temporary set of keys on each connection and never persists any of it to disk (so storing the communication with the hope of eventually grabbing the keys from the user's machine by virus or social engineering or just plain ol' physical theft doesn't even make any sense the same way GPG-encrypted email does).
This already exists. It's just not a single, all-in-one tool - the answer is to use a tool that's fit for the specific purpose you're trying to accomplish (secure messaging, encrypted backups, encrypting application data, etc.)
There is not, and never will be, a modern one-size-fits-all approach because the entire industry has moved on from that model - over the last 30 years, we (collectively) have learned that it's inherently insecure to design a tool to do so many disparate things and expect people to use it correctly each way.
It exists, it's called age..
Some random links
https://github.com/FiloSottile/age
https://www.reddit.com/r/crypto/comments/hr64hr/state_of_age...
https://github.com/FiloSottile/age/discussions/432
> (Acquiring keys, rotating keys, identifying compromised keys, and most importantly either reaches a large enough percentage of emails..
Oh nevermind, age doesn't do any of that. Indeed, it doesn't even do email https://github.com/FiloSottile/age/issues/93
I'm not joking, it's genuinely user-friendly, and I certainly prefer it over GPG.
Interestingly, its simplicity makes everything about GPG suddenly make more sense.
Now send a file encrypted by age to two addressees, who don't need to know each other's decryption keys.
After that, sign an email without encrypting it; do the same with a git commit, or a Debian package.
GPG has features well beyond the simple encryption (which age does) because there are real uses for that.
But I think the outcome of this is not "something fresh" but rather "giving up on the idea of encrypted emails altogether". We have far superior communication channels that are secure, easy and private today (Signal, Matrix, WhatsApp, iMessage); That problem is solved. Storing emails secure and encrypted is solved too, by providers such as protonmail, fastmail, tutanota and many others.
So what does GPG/PGP really solve still?
The one use-case that I strongly see it shine, is where mail-notifications are signed. I've only ever seen Kraken do this: Upload my GPG/PGP pub key in their web-interface, and have them sign and encrypt mails to me with that. It very much solves phishing and MITM on email-notifications (and password reset mails and such). Comes with two serious problems though: the UX on my client-end still sucks; e.g. I never managed to set-up PGP on my android client, so I cannot read their mails from my phone. "subject: Login attempt from X" body: garbled. And generation and rotation of the keys is as frustrating as ever. It certainly is not a feature for "my mom".
UI:
"billing@paypal.com: we never seen this sender before, be careful"
"billing@paypal.com: this is verified to be the same sender"
"billing@paypal.com: ACHTUNG! THIS IS SOMEONE ELSE"
Headers aren't part of an encrypted or authenticated body, so this is trivial to perform a key replacement attack against.
DKIM can be leveraged for that, although DKIM is one hell of a gun to give someone to shoot themselves.
If you're connecting to an SSH server for the first time and don't already have a pre-established host fingerprint, then yes: someone who controls your server's DNS records can redirect you to another SSH host, which you'll then (presumably) enter your password into.
One of the many arguments for using pubkeys so that's all they'll get. Neverthless, the rest of the session could still be anything, and agent forwarding should never be used for untrusted hosts.
gnupg looks like something that actually can keep your secrets (at rest, otherwise a less-likely-to-backdoored convenient option is Telegram).
Do your own research. I found the initial links on hacker news.
None of which are anywhere close to as ubiquitous as email. None of which are well suited to long messages. Only one of those (matrix) is federated. Only one (matrix) wasn't designed specifically for use on mobile devices. Yes, the others can be used on a desktop, but the experience isn't great.
Everyone I know uses email. No one I know uses whatsapp. A couple of people I know use Signal. A handful use iMessage.
> But that doesn't matter, because in this discussion, the figure of merit is encrypted email,
Ok, let's consider one case where encrypted email is commonly used: reporting security vulnerabilities. Do you really think any of these would be a good medium for that? Do you see companies or other organizations putting a whatsapp username as the contact in their security.txt?
I do want there to be a more secure replacement for email. But most of the newer e2ee messaging systems can't really fully replace email.
It's not authenticity that matters here, it's confidentiality.
Right…
Despite my reluctance to use Meta projects, I read and write far, far more WA messages per day than emails.
How do you manage the keys? If you've shared them with a team, how do you ensure someone hasn't taken a copy? What if the key is lost? What if someone ends up replying to the thread without doing the encryption song and dance? It's just such a pain. I'd rather copy and paste something out of Signal and into my bug tracker a thousand times than have to deal with all the footguns of email encrypted with GPG.
This never made sense to me, can anyone explain?
These are valuable tools, but they aren't usable on the command line the way gpg is. Signal doesn't help me sign an update to my software package.
Also I think the web of trust is a pretty cool concept, in theory at least. I don't know if anything outside GPG supports it.
Most people don't even care about security. You can't protect people who won't care to protect themselves.
After a while, you sort of want bad things to happen so society will move forward... Humans are so reticent to act to protect themselves from a threat they don't see or understand the capabilities of.
It doesn't pass the smell test. FB has been caught numerous times mishandling data. Apple is a walled garden you can't trust, same with WhatsApp. Unless Signal is liberally licensed, we can't verify privacy there.
Also, using a phone number as an ID is a de-anonymizing technique. Industry absolutely does not do this correctly, or they wouldn't be a juicy source of analytics data. Governments court these companies to exfiltrate data they have on people. If the data were adequately protected, they wouldn't be able to do this.
Sending something over HTTPS is encrypted but it's not private to the other end. Nice sleight of hand but I actually understand what I'm talking about.
https://news.ycombinator.com/item?id=38537444
In any case, it's better then using plaintext. It's probably safe enough against non nation state actors.
There was a year or two where I actually began to receive autocrypt headers from random people and started encrypting with them.
Unfortunately, this momentum was completely killed by thunderbird, who decided to remove support and proceed to reimplement traditional manual email encryption :(
I'm working on this! It's called Stamp (https://stamp-protocol.github.io/) and takes a lot of the issues I've had with PGP/GPG and creates a more modern refresh. It's definitely not simple but my hope is that having sane defaults and writing good interfaces will help with this.
Unfortunately it just went through a rearchitecting and the docs are horribly out of date, but the basic concept persists. In the current version instead of having different hardcoded key types (alpha, publish, etc), there's now the concept of "admin keys" and "policies." Policies decide what keys can do what as far as managing the identity, so it's possible for instance to have a policy that gives a key god powers, or a policy that sayd "if three of these four signatures match, the entire key and policy set can be replaced" (aka, multisig recovery machanisms). Also, in the current version, "forwards" have been entirely removed and replaced by claims.
The goal is to use this as a means to act as an identity in p2p systems. My issue with p2p systems is that they always punt on identity, making it a function of your device and some randomly generated keypair. That said, Stamp can definitely be used more generally.
Right now I'm focusing on the underlying network that syncs identities between devices and also stores identities publicly, circumventing the need for keyservers and all that stuff.
But fundamentally there's no money in it. GPG is Like That largely because it's maintained by a grand total of one (1) guy, which is all the OSS community can afford to fund. Who's going to pay for a crypto platform, except when it's the CIA (or equivalent) sponsoring useful idiots?
It is a serious problem that the ecosystem is held back by wasting resources on personal disputes with immediate consequences for end users.
Hate on OpenPGP all you want, it still is an important technology with unrealized potential and growth.
There is 100% value in being able to decrypt a 20 year old email. It doesn't matter if it is a broken cypher.
A 20 year old email has very little actionable in it, but can have value in other ways.
It is absolutely vital that a project like this, supports some means for a modern machine/stack to access older data.
Upstream spoke of deprecated support for older emails. My response is aimed there.
And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github.
A project like this, needs to maintain backwards operability. For decades.
What's really being asked for here is the capability to seamlessly continue sending messages with the previous, weak constructions, into the indefinite future, and have the installed base of the system continue seamlessly reading them. I think that is in fact a goal of PGP, and one of its great weaknesses.
Users who still rely on that have to use the old software, against which there can be barriers:
- old executables don't run on newer OS (particularly in the Unix world).
- old source code won't build.
- old code won't retrieve the old data from the newer server it has been migrated do.
Things like that.
The barriers could be significant that even someone skilled and motivated such as myself would be discouraged.
Not all reliance is reasonable though.
Some legacy software can only do SSLv3 or lower, does that mean the rest of the internet has to carry that support around? Abso-f-lutely not.
The same applies here. If you really need that ancient stuff that loses support, repackage them in newer encryption or remove the obsolete layer. It's highly probable that information no longer needs to stay encrypted at rest anyways.
That is how it works. What you're missing is that everyone, both servers and clients, agrees that supporting old SSL versions is a bad idea. And they're right.
More precisely, I don't agree with web clients not connecting to old servers.
Plain HTTP is what people resort to when their browser refuses to connect to an old device or server using HTTPS, which is worse than old SSL.
The absurd idea that a user will have a 20 year old encrypted mail, because software still supports it, is ridiculous. What really happens is someone has a 20 year old mail no matter what, itcwill always exist, and the choice is, support it or not. Support it to be read, support it to be converted, warn the user, suggest fixes.
And your SSL example is senseless! In what world do you envision super secure stuff alongside weaker legacy, on the same damned server. You literally are not thinking sensibility about any of this, you examples are paper tigers.
This stance is absurb.
How do you alert the users that are running the problematic software and haven't yet updated it? The very premise is ridiculous.
> What really happens is someone has a 20 year old mail no matter what, itcwill always exist, and the choice is, support it or not. Support it to be read, support it to be converted, warn the user, suggest fixes.
Well yeah and the choice should be to not support it. If the user needs those letters they can either decrypt or just re-encrypt them. It's silly to claim that a message can somehow be both so vital to be protected by encryption, but not upgraded to something more modern.
> And your SSL example is senseless! In what world do you envision super secure stuff alongside weaker legacy, on the same damned server.
I'm not envisioning it. Nobody should be running such old useless garbage. What was suggested earlier in this thread does not work and must not happen in practice.
Where did you get the weird idea the software isn't updated? This entire discussion is about deprecation of older encryption methods in new versions of software.
You're not giving this thought. Good day.
In the trouble situations, one of the two pieces of software being upgraded is thrust upon the user.
Only when we are doing theatre. In the actual facts, lack of security is worse than inferior security.
(This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)
It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome.
That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?
Put another way: your cryptosystem isn't responsible for saving your ass from not making backups. If your data is valuable, treat it that way.
This is exactly why your crypto system should not rely on spontaneously writing many gigabytes on a read operation, without asking. I couldn't have said it better myself.
What you are advocating is crypto intruding on the storage mechanism inappropriately. It's a layer violation.
I think if it's important to the end user, you could write fairly decent code at the app layer that asynchronously re-encrypts old data in a way that doesn't harm the user. That code would need to have a strategy for write failures. A basic cryptography tool should probably not have this as a built-in feature however, for a few reasons including those I've stated.
Again: nobody has said this.
Whether or not the tool does this in bulk, or asynchronously, or whatever else is not particularly important to me. The only concern I have in this conversation is whether it's contradictory to simultaneously assert the value of some data and refuse to encrypt it correctly. Which it is.
You said it. You said that's what the cryptosystem should do. It's a bad design.
From the original comment:
> This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes
Is there a real risk of this that I missed, or are you just free-associating off the term "backwards compatibility"?
There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible.
See 'A Critique on “A Critique on the OpenPGP Updates”':
* https://blog.pgpkeys.eu/critique-critique
Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format.
The Proton folks are choosing to support both v5 and v6:
* https://github.com/ProtonMail/go-crypto/pull/182
As is the Thunderbird/RNP team:
* https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...
The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.
Can you explain why?
People elsewhere in this thread are saying that PGP sucks because it tries to do too many things at once, but it seems to me that the one big advantage of a tool which does everything at once is that you only need to solve authenticity one time for everything you do.
For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
Well, the key servers are useless because they are susceptible to that poisoning attack from a few years ago, and they happily send you fraudulent or revoked keys.
And the web of trust doesn't scale. The trust ratings mean different things to different people, the propagation of revocation certs and signatures is slow, and rotating keys is onerous.
>For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key? (Haha just kidding, PGP users essentially never rotate keys)
If you care enough to encrypt your emails, then what is the virtue of verifying less frequently that you're talking to the correct persons?
Why wouldn't you want separate keys for all those things?
Why would you want an adversary to be able to compromise a single key and have the ability to forge commits, emails, and whatever else?
I'm almost certain PGP best practice is to have a single master key, kept on an airgapped device, that's used to sign subkeys for various purposes like email, commit signing, etc. So I only have to verify out of band once, unless the airgapped device gets compromised or the master key encryption is broken.
More importantly, how do you know that your counterparty is one of that (extremely small) minority?
Don't forget about PGP smart cards either. You could keep the master key you use to sign subkeys on a smart card. A smart card should be harder to hack than your phone.
Qubes has built-in "split GPG" support that allows you to e.g. sign something using your private key while keeping it in a different VM. See https://www.qubes-os.org/doc/split-gpg/
I know PGP isn't for everyone, I just like the idea of keeping high-security options available for those who want them.
>More importantly, how do you know that your counterparty is one of that (extremely small) minority?
You could ask them :-)
But PGP doesn't provide a high-security anything.
- In order to achieve some reasonable level of protection from MITM attacks you can't just get someone's key from a keyserver. You have to go hunting for it and you're never really sure if there's a revocation cert out there that you just missed.
- Some people publish PGP keys on their websites, and you could use that to contact them over encrypted email. You are still vulnerable to metadata analysis and unless you manually re-key on every message (which you don't), you don't enjoy forward secrecy. Additionally, all it takes is one oopsie moment for someone to Reply-All and forget to encrypt first and now the entire conversation went out unencrypted. This has happened to me.
- You claim there's some unspecified benefit to signing commits with the same key you encrypt your emails with, though I don't see why that's superior to signify/minisign
- Best practices demand that you keep an airgapped machine with a long lived master key on it. No mention is made of how to prevent BadUSB-type attacks from jumping the air gap. If you really want to be sure nobody mints their own key from your airgapped machine to impersonate you, you now need to monitor your machine. That raspi in a drawer is still vulnerable to Evil Maid attacks, and the worst part is you won't know someone's impersonating you until it's too late.
All this attack surface just for the purported convenience of having some kind of unified "crypto identity" wherein you only need to verify someone once?
These are not the characteristics of a high security system. This is why people think PGP is a for security LARPers. It's objectively just not a very good tool.
This is a convenience consideration, not a security one.
>- Some people publish PGP keys on their websites, and you could use that to contact them over encrypted email. You are still vulnerable to metadata analysis and unless you manually re-key on every message (which you don't), you don't enjoy forward secrecy. Additionally, all it takes is one oopsie moment for someone to Reply-All and forget to encrypt first and now the entire conversation went out unencrypted. This has happened to me.
These are problems with encrypted email, not PGP. Encrypted email is not the only way to use PGP. See e.g. https://news.ycombinator.com/item?id=38575764
>No mention is made of how to prevent BadUSB-type attacks from jumping the air gap.
You could write newly minted keys to single-use CD-Rs.
>If you really want to be sure nobody mints their own key from your airgapped machine to impersonate you, you now need to monitor your machine. That raspi in a drawer is still vulnerable to Evil Maid attacks, and the worst part is you won't know someone's impersonating you until it's too late.
If physical access is part of your threat model, you'll want to monitor access to your stuff anyways.
That said, I agree with jandrese's point about key management -- low-security key management solutions shouldn't prevent people from taking a high-security approach. Seems like the ideal situation would be if the really paranoid people end up naturally testing the low-security infrastructure as a side effect of doing their paranoia stuff. E.g. if the gpg client was set up to automatically report discrepancies between a user's personal web of trust and a presumed-authoritative keyserver.
That said, it's unclear to me why Signal wouldn't have worked for Snowden -- interested to explore details here.
What is the alternative KM architecture in a distributed system? Remember that for e-mail there is no central authority to handle assigning keys to individuals, unless perhaps you want Gmail and Outlook.com to handle that.
The other e-mail security system is S/MIME (which uses X.509).
Sure if someone knocks over TLS then your email encryption will be in trouble, but you will also have plenty of other problems at that point.
This is actually possible for OpenPGP, with WKD ("Web Key Directory"): https://datatracker.ietf.org/doc/html/draft-koch-openpgp-web...
It's an expired draft, but is relatively widely supported: https://wiki.gnupg.org/WKD#Implementations
It should have been in mail systems forever. Whenever you create an account the first email should have been the server sending you your private key in some format that every email client understands and would then prompt you to automatically install it in your client for that server.
Welcome to your new email account!
Your private key is attached in the standard format.
When your client asks you to install the key say "Yes", and allow it to automatically sign your email using that key for this account.
Don't forget to check the box to automatically encrypt mail when possible.
Even before that, there were other mechanisms proposed for this, such as https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp... (from 2003). Unfortunately it didn't catch on; I agree it would've been nice to have such a mechanism earlier.
We've implemented this at Proton: https://proton.me/support/key-transparency (although it's still in beta, and opt-in for now - but obviously the aim is to enable it by default).
There's also a (relatively new) working group at the IETF, to work on standardizing (a version of) this: https://datatracker.ietf.org/wg/keytrans/about/.
Really paranoid folks could set up services online that check for this, but I kind of doubt it would happen very often because it would be a major stink for that email service if they were caught, and catching them isn't that hard.
The problem with existing keyservers is that there are several of them and you never know which one someone's public key might be living in. There may even be multiple potential keys for a single email address across the different servers. They are effectively useless for email encryption in their current form. It's a very rare email client that will even query the most popular ones looking for someone's key. In fact I don't know of a single email client that does.
Certificates in DNS, 2006: https://www.rfc-editor.org/info/rfc4398
Just yesterday I was frustrated that gpg didn't work very well in my terminal for some reason (the barrier between entering the data and the password was weirdly permeable, i.e. sometimes some of my password ended up in the data, and more often a lot of what I pasted ended up in the password prompt).
So I found openpgp.js and made a little website where i can encrypt and decrypt my secrets.
I used that particular library because it feels safe that the things I have encrypted can be decrypted with a tool that is accessible everywhere... as long as I can remember the passwords :)
But I wonder, are the defaults for symmetric encryption in openpgp not considered safe anymore, or how should i interpret some of the other comments here?
That would be AES. The traditional OpenPGP authenticated encryption (OCFB-MDC) is secure. There has been some widespread misunderstanding, I wrote a rambling editorial against the idea of superseding the block cipher mode:
What's that?
That is perhaps what all of these replacement schemes fail to realize.
I really wish "Login with PGP" was a thing and use a subkey for each website, with optional ability to hide the identity of a particular website in my own keychain. You know, sorta like passkeys, but I don't have to have Google/Apple/etc involved and I can actually inspect the magic behind the scenes.
Strong words, but why?
PGP doesn't do this: PGP key has a claimant identity, but actually verifying that claimant is left to the end user. That's why the WoT and strong set were important (before they violently collapsed, revealing that they weren't load bearing after all).
Other schemes do realize this, and it's why they make tradeoffs around trusted parties (CAs in the Web PKI performing domain validation, EV for code-signing, etc.).
I hadn't heard they violently collapsed; do you have any links where I can learn more about this?
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...
Also, as someone who went to a few signing parties: the strong set was probably never as strong as some people thought.
How well would such sites handle PGP subkey revocation? What about PGP key revocation?
Revocation is very important if your key is compromised.
I haven't seen any really maintained pgp keyserver or service in general that didn't directly or indirectly (by user/agent mistake) fail spectacularly since https://evil32.com/ was released and contaminated the 32bit key id space.
PS: Photon hosting private keys is, to me, a nonstarter. It makes their entire platform and investment in GPG pointless.
It's not an important rule if security is your primary concern. Because if you "don't break shit", the first thing any adversary will do is to try downgrade things until an old, insecure state.
The way to counteract that is to refuse to downgrade, which obviously breaks shit if one of the sides can't speak the new protocol.
The whole format for encapsulating PGP data is extremely complex and in some parts insecure. That's an excellent reason to rethink the problem.
In my understanding, this is not about "adding bits" or changing algorithms, it's about the level above. The packet format that says "This is the algorithm, this is the hash being used, this is the data, etc, etc".
"The PGP MDC can be stripped off messages –– it was encoded in such a way that you can simply chop off the last 22 bytes of the ciphertext to do that. To retain backwards compatibility with insecure older messages, PGP introduced a new packet type to signal that the MDC needs to be validated; if you use the wrong type, the MDC doesn’t get checked. Even if you do, the new SEIP packet format is close enough to the insecure SE format that you can potentially trick readers into downgrading; Trevor Perrin worked the SEIP out to 16 whole bits of security .
And, finally, even if everything goes right, the reference PGP implementation will (wait for it) release unauthenticated plaintext to callers, even if the MDC doesn’t match."
TL;DR, the packet format has "${DATA}${SIGNATURE}", in such a way that you can strip $SIGNATURE, do whatever you like with $DATA, and it'll go through because this is a backwards compatibility mechanism. Former versions didn't have $SIGNATURE, so any attacker can just get rid of it, and problem solved.
This is I repeat not a case of "maybe there's some PHD level math we're unaware of", but absolutely glaring issues.
You don't need a genius to write a formal proof of why allowing people to strip signatures is a bad thing.
And it's a problem solvable by throwing out the compatibility scheme and adding a hard requirement.
I've been using PGP for decades at this point and I'm still somewhat surprised when I encounter security professionals that either can't figure out how to use PGP or just ignore it because "its too complicated, and I already have Signal". I have no beef with encrypted messenger services but it's not the same use case as PGP for email and other needs.
This also hints at a separate cultural divide. Young people only know email as that thing you need in order to setup other accounts. They use IM for the bulk of their real communication and at best consider email something they only use for work. Only old farts think of email as something they use for personal correspondence. And frankly, most of the people I interact with are younger than me so most of my communication has shifted to where the people are that use it, which is IM services.
I think perhaps what you mean to say is that experts like the x509 PKI. Which again, isn't quite true. You'll find plenty of experts pointing out that major parts of x509 and the PKI ecosystem, and of TLS and HTTPS, are garbage: ASN.1 parsing is a trashfire, protocol/cipher negotiation has had numerous critical flaws, things like compression have allowed traffic to be decrypted.
What I think is more accurate to say is that experts have invested heavily in finding ways to augment web infrastructure to remove broad categories of these, and the result is a generally recommendable system. This includes things like moving to TLS 1.3, enforcing that CAs participate in Cert Transparency logs, delisting CAs that misbehave, and adjusting browser behavior to avoid security pitfalls like mixed content that compromise users.
The problem with doing that for GPG is partly that its fundamental nature is not well aligned with making those kinds of changes, and partly that (as we see in the original post) GnuPG is resistant to making changes that would leave behind users of insecure codepaths and cryptography.
It's getting really hard to take you seriously. You hate gpg, you hate pki and you always claim to know better than industry standards without providing any details whatsoever.
I'm pretty comfortable with who does and doesn't take me seriously, for what it's worth. You don't have to if you don't want to.
> I'm pretty comfortable with who does and doesn't take me seriously, for what it's worth. You don't have to if you don't want to.
Cool. Happy for you bro.
Without a serious use case hanging in the balance, this is just OSS drama.
I am also aware that you are actively involved in moving ecosystems away from PGP and towards solutions in the Sigstore ecosystem, so this is definitely not news to you. I understand you want the situation to change, but for now it's disingenuous to pretend like GPG in particular doesn't have the super majority of "market" share around signatures and that drama like this wouldn't have potential impact to a lot of folks.
No, that would be bespoke PKIs on various proprietary OSes. PGP is miniscule compared to any of these; it's not even a rounding error. This is true even when you juice the numbers with things like git signing (which is not only ignored by 99.9% of clients but doesn't even sign the relevant software artifact for end users).
> I understand you want the situation to change, but for now it's disingenuous to pretend like GPG in particular doesn't have the super majority of "market" share around signatures and that drama like this wouldn't have potential impact to a lot of folks.
If you know me, then you know I've run the numbers here[1]: even ecosystems that encouraged PGP use for decades have all the hallmarks of the signatures being completely unused. End users do not verify PGP signatures, signers do not maintain their keys; PGP's tooling encourages this behavior.
I won't deny that workflows will be broken by moving away from PGP. But those workflows are (1) a tiny, tiny minority, and (2) overwhelmingly security theater, especially now that PGP's principle feature (the WoT) is dead.
[1]: https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI...
I have read your blogpost and I agree that PyPI had unused and useless PGP support. I also agree that signatures are a waste of time when the client tooling does not verify by default. However, this is not true for the Linux distro packaging ecosystem where approximately all downloads have their signatures verified. Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
Don't mistake me as a defender of PGP-the-standard. I have absolutely no opinion on its cryptography. I would happily use minisign or any other tool that used only modern cryptography to produce signatures. As a distributor of software though, I don't really get to decide how to sign, I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.
I have a strong suspicion AuthentiCode is similarly common, plus a certain winner outside the server space.
This is probably true, for Linux. Windows does its bespoke PKI thing with Authenticode; OpenBSD uses signify[1].
> Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
This is a fair point! But I'll point something important out: these platforms are essentially using PGP as a dumb key encapsulation format; they benefit (correctly!) from being able to pre-baked rings of trusted distribution keys. The fact that they use PGP for this is an implementation quirk, one that has materially negative consequences[2].
It's not easy for them to switch, but all of these platforms would be well (better) served by switching from PGP to signify, minisign, or similar.
> I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.
Out of curiosity: which government standards? I'm not aware of a US Gov't standard that mandates PGP; this would be very valuable to know.
[1]: https://www.openbsd.org/papers/bsdcan-signify.html
[2]: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
It's interesting to consider third parties who maintain Linux package repos, like Postgres https://ftp.postgresql.org/pub/repos/yum/
They distribute their public keys on their own web infrastructure, so it's effectively TOFU. In your criticism of PyPI, you rightly pointed out that keys are useless unless pushed to a publicly-known key server because they aren't discoverable for users, which leads to ~no one verifying installs. I agree with this for PyPI, but in Postgres' case, if you do not have their key pulled locally, installs will fail by default. This means that users do generally install keys locally (actually they typically install the repo RPMs which configures local repositories as well as installs keys), even if the discovery mechanism isn't enforced by yum. My point here is that ecosystems without the ability to pre-bake rings of trust can still result in ~all downloads being verified as long as the client tooling defaults to the correct thing. pip not doing so is the main reason why OpenPGP signing never caught on in the Python ecosystem.
But yes, I agree: A modern day dpkg and rpm could swap to something with safer cryptography rather easily without changing anything about distribution. OpenPGP is a lot of bloat for their needs.
> Out of curiosity: which government standards? I'm not aware of a US Gov't standard that mandates PGP; this would be very valuable to know.
I don't believe any mandate OpenPGP specifically. I was more trying to get across that many institutions mandate FIPS 140-2/3, and current implementations (like on RHEL) complain if signatures are not present in their expected format. Because OpenPGP is my only choice for signing yum infrastructure and RPMs, it's a de-facto government standard today.
So there are certain assurances that keys in the keyring got verified.
Which is fine; the centralization here makes sense, for the same reason I trust Microsoft to give me Windows updates or McDonalds to give me fries and burgers. But it's no more "web of trust" than either of those examples.
Because these cryptographers haven't actually delivered anything else that's actually usable by people who just want to encrypt the bodies of their emails?
[1]: https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
And note that I specifically said "people who just want to encrypt the bodies of their emails". That is still incredibly useful, even if the metadata is (obviously) not encrypted.
> That is still incredibly useful, even if the metadata is (obviously) not encrypted.
To whom? What is the threat model in which a user who is serious about the security of their messages is better served by PGP-over-email?
Research about online black markets (which serves as a nice "case study") will show that the main form of communication between people there have been pasting a PGP encrypted message into a text box and sending it, and sometimes literally using email.
In a situation like this, where anonymity and privacy are critical, signal is not even remotely an option because it requires a phone number.
Matrix may be possible to use, but it would require that someone run a matrix server that allow people to make accounts with no information required for sign up, and allow signup and use of the server over tor, which are all unlikely.
PGP over email or pasted into a web form is simple, it doesn't require signing up with a phone number or any PI, it can be used over tor, and it can be done with basic utils installed on almost any Linux distro.
I suspect a lot of cryptographers have not done research about what goes on "in the real world" or "in the wild". It would be interesting for them to setup a mock situation where two people attempt to send messages to each other without doing anything that could identify them in any way, completely anonymously, to emulate what using these tools in the real world would be like for a whistleblower or journalist or whatever.
PGP is not a serious answer here.
[1]: https://www.justice.gov/sites/default/files/opa/press-releas...
Consider the ANOM[1] case: the FBI found it easier to FUD criminals into using a backdoored chat app than to break actual chat apps.
[1]: https://slate.com/technology/2021/12/fbi-fake-encrypted-mess...
I think the usability complaints here are very valid, but chlorion has a good point that PGP still wins for particular use cases. Heck, if you're really paranoid [and metadata is not your primary concern], use PGP over Signal. I don't think any of the alternatives proposed in this thread are chainable in this way like PGP.
There's one critical difference, however: governments have identified Signal and its ilk specifically as a threat to their intelligence gathering capabilities. They don't talk this way about PGP; the public signals overwhelmingly indicate that (1) virtually nobody uses PGP for anything worth surveilling, and (2) anybody who does use it for things worth surveilling bungles it (see above). Thats the government's dream!
> Heck, if you're really paranoid [and metadata is not your primary concern], use PGP over Signal. I don't think any of the alternatives proposed in this thread are chainable in this way like PGP.
This doesn't make sense. What is the "paranoid" model in which PGP provides (1) better cryptographic guarantees and (2) metadata isn't your primary concern? PGP cannot provide forward secrecy, provides all-around weaker cryptographic primitives, and is significantly harder to use correctly. It isn't a rational choice for a paranoid actor to make.
I think you must have misunderstood me. By "PGP over Signal" I meant PGP-encrypting messages and pasting the ASCII-armored ciphertext into the Signal client. The idea being that even if the NSA can break Signal's crypto, they might fail to also break whatever crypto you select with PGP. I should have said "both PGP and Signal", sorry for the poor communication.
I acknowledge PGP's flaws, but I like it as a ubiquitous DIY tool. I'm hoping that niche gets filled with something better. Though to be honest, I think for the "ubiquitous DIY tool" niche, forward secrecy might just be impractical.
> The idea being that even if the NSA can break Signal's crypto, they might fail to also break whatever crypto you select with PGP.
This is an intuitive idea, but I’ll also hazard that it’s probably security theater: at a “building blocks” level, a theoretical NSA that breaks Signal’s crypto has broken the finite subgroup problem that underpins all of PGP’s cryptography as well.
(The reality is that the NSA doesn’t crack this kind of cryptography, at least not when it’s done correctly. They’re much bigger fans of exploits and implants, which they are absolutely not wasting on “ordinary” criminals.)
Even if the math itself is bulletproof -- as you stated, there could be an implementation flaw in either the Signal code or the GPG code that effectively bypasses the math, right? See e.g. https://en.wikipedia.org/wiki/GNU_Privacy_Guard#Vulnerabilit...
>They’re much bigger fans of exploits and implants, which they are absolutely not wasting on “ordinary” criminals.
The ASCII-armor scheme I described could be helpful here too. Run Signal in a VM (e.g. with Qubes -- endorsed by Snowden). Copy/paste ciphertext in and out of the VM to GPG. Should be fairly idiotproof because ciphertext doesn't look like plaintext. Now even if the NSA sends you a Signal message that owns the VM, they still need some sort of VM escape/CPU sidechannel, or else knowledge of a vulnerability in GPG's encryption.
>The Rule of Two is a data security principle from the NSA's Commercial Solutions for Classified Program (CSfC).[3] It specifies two completely independent layers of cryptography to protect data. For example, data could be protected by both hardware encryption at its lowest level and software encryption at the application layer. It could mean using two FIPS-validated software cryptomodules from different vendors to en/decrypt data.
>The importance of vendor and/or model diversity between the layers of components centers around removing the possibility that the manufacturers or models will share a vulnerability. This way if one components is compromised there is still an entire layer of encryption protecting the information at rest or in transit. The CSfC Program offers solutions to achieve diversity in two ways. "The first is to implement each layer using components produced by different manufacturers. The second is to use components from the same manufacturer, where that manufacturer has provided NSA with sufficient evidence that the implementations of the two components are independent of one another."[4]
https://en.wikipedia.org/wiki/Multiple_encryption
As for implants, that's going to require physical or root access as a prerequisite, no?
Sending credentials to a coworker, for example. I don't care who knows that I emailed them. I don't even care if they know what it's about (database credentials), as long as they can't get the actual credentials simply by accessing the mail server. I don't have to set up any new infrastructure (not realistic within most orgs), all that is needed is for both parties to use gpg.
Most of these distros are using PGP to distribute software, often binaries that are distributed to end users.
Gentoo as an example, requires all commits to the gentoo repo to be signed by a key in the "gentoo-developers" keyring. Gentoo also provides "stage3" images which are signed by the "gentoo-release" key. Since this is a source based distro there are no binary packages, but the main ebuild repo is signed and verified upon syncing.
I know some other distros like Arch also do similar things with PGP.
Maybe you will say that this isn't actually using PGP because it's not using the "web of trust", but I don't think this is relevant, because there is much more to PGP than the WoT and those features are being used.
PGP for signing email however has been a perpetual failure. Decades later they still have not figured out a reasonable key management system, which left the community fractured and unable to scale. As you note, the Web of Trust has been a disaster for everybody except the most exceptionally paranoid who can't accept anything less. And those people talk to so few other people that they don't have the scaling issues that regular people face.
(via https://news.ycombinator.com/item?id=38554943, but we merged most of those comments hither)
It might be useful to wait three months and revisit LibrePGP and the OpenPGP WG and see what progress has been made.
Assurances that, don't worry, it's all gonna be backward compatible, are neither here nor there, from that perspective.
This kind of governance issues make it pretty clear that won't ever happen
So far the only practical incompatibility I have seen seems to be associated with the GnuPG OCB cipher mode. Newer versions of GnuPG generate keys that show OCB compatibility. So encrypting messages/files to that particular PGP identity will result in the use of the non-backwards compatible OCB mode. That will prevent a non GPG OCB compatible from decrypting the message/file. The GnuPG project should document the issue and make it clear how one could disable the GPG OCB mode.
More: https://articles.59.ca/doku.php?id=pgpfan:authenticated (my article)
>the PGP MDC is as secure as an authenticated cipher mode.
It is. It turns out there is a class of authenticated encryption that involves first hashing the plaintext and then encrypting the plaintext and the hash. OCFB-MDC seems to be an instance of that class. That seems to defy conventional wisdom and as a result is interesting.
More: https://articles.59.ca/doku.php?id=pgpfan:mdc (my article)
I wonder up to which extent this has to do with the Mochizuki v. Scholze and Stix disagreement?
I say this because as far as I know: elliptic curves are the state of the art in crypto,
and the IUT theory (mochizuki's) has a lot to do with elliptic curves
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.
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.
[0] https://www.adobe.com/sign/hub/how-to/how-banks-use-electron...
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 :)
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.
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.
"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.
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.
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.
I agree. Thing is, asynchronous communication is a killer feature. My primary communications channel is email, but I don't use encrypted email.
I do use GPG, but not for email.
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?
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.
> they don’t just knock PGP, they very often mention alternatives
What alternatives do they mention?
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.
https://support.signal.org/hc/en-us/articles/360007059752-Ba...
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 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.
And they'll just switch to WhatsApp.
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.
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.
"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.
Though yes... it's more secure than SMS.
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?
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?