[defanor]

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availability issues. Almost nothing of that is available from Linux distributions' system repositories. Integration with other software and infrastructures is lacking. Dealing with multiple specialized tools is more of a headache even for expert users, especially when their added benefits do not make much sense given one's threat model. OpenPGP/GnuPG is more resilient and versatile than those, still usable where those are not.

I think such an article would seem more convincing, at least to me, if more sensible alternatives were proposed. Ideally without the advice to not encrypt email, without assumptions of continued availability of all the online services, of trust to certain third parties, and so on. Or it could be just a plain criticism without suggestions, which would still be somewhat informative.

Edit: there is another list of alternatives in a sibling comment, advising against (well, actually being quite hostile towards, and generally impolite) usage of what I had in mind as one of the possible more sensible alternatives: XMPP with OMEMO. Though upon skimming the criticism of that, I have not found it particularly convincing, either, and it just looks like some authors try to be particularly provocative/edgy.

[jeltz]

What is your issue with Sequoia PGP? It is not proprietary, it is not centralized and it is much better than GunPG from what I can tell.

[defanor]

I have no issues with it, and actually happy to see alternative implementations. Possibly because I did not use it much, but it does look fine to me. Not as a complete GPG replacement yet, since some software still depends on GPG, but a viable one, and a suitable one for most of the manual CLI usage (ignoring that its version on slightly older systems has a different interface, adding a bit of confusion; hopefully it is stable now). It was not listed among suggested alternatives in the linked article though, and from what I gather, the author would not be happy with it, either.

[tptacek]

Since you mentioned me: what's the point? It would be one thing if you could (1) use Sequoia, (2) be assured of modern cryptography, and (3) maintain compatibility with the majority of the installed base of PGP users. But you can't. That being the case, why put up with all the PGP problems that Sequoia can't address? You're losing compatibility either way, so use an actually-good cryptosystem.

[defanor]

(Sorry for the relatively long post; it so happened in an attempt to explain my point of view in more detail. I think variations of that do come up in such discussions, but staying unnoticed or dismissed; maybe this one will succeed.)

Probably because of my limited usage of Sequoia, but it seemed compatible enough with GnuPG (when it comes to OpenPGP, that is; not their CLIs or APIs): not completely, but enough in practice. The cryptography also looks modern enough to me: it is not like even GnuPG defaults to compatibility with particularly old systems.

If they were notably incompatible though, I guess I would prefer GnuPG for the availability and compatibility reasons, as mentioned above, mainly to avoid fragmentation. Though if there was a better system, as versatile, preferably as easily available, even if not as widely used, I would consider that as well.

Apparently the threat models we have in mind, along with the settings to use those tools in, differ: as mentioned in the sibling comments, my concerns (or past concerns, current issues to deal with) are more about availability, confidentiality in the face of mass surveillance and over varied channels (i.e., versatility). I see (and hear of) people neglecting cryptography altogether in cases where cryptography would be beneficial (for confidentiality, most often), the local government and other threat actors focusing on heavy-handed and basic attacks (aiming to disrupt use of cryptography, such as by blocking the IMs they do not control and other online services, or--perhaps even more often--making use of it not being used at all in the first place); so I struggle to see how, say, age + minisign would have helped anyone over GnuPG in such conditions, or even those rare few who are targeted individually. But I find it much easier to see how a wider adoption of any sufficiently good, versatile, available, and standardized/compatible tools would be useful. So that people would be able to communicate securely using those, as well as the same person would be able to easily decrypt a file they had encrypted years ago without keeping around a toolbox of varied--and likely partially abandoned--tools, which, taken together, would likely be a worse legacy pile of software and algorithms than OpenPGP and its implementations, moving the specification with its different legacy options into users' heads (and replacing the implementation with their manual operations).

Of course everyone having and properly using a set of most polished and foolproof tools implementing algorithms considered most secure (out of practical ones) at the time would be good, but there are issues with adoption, software acquisition and updates, interference (i.e., adverse conditions, including blocking), key distribution, as well as the moving target (changing recommendations/views) to take into account. The algorithms, implementations, and UIs are not to be ignored, but neither are they everything there is, so one has to prioritize all the components.

[tptacek]

The issue is that the modern cryptographic stuff Sequoia does isn't compatible with installed GnuPG. You can use Sequoia compatibly, but by doing so you're surrendering their cryptographic improvements.

[woodruffw]

One of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter.

(Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one prominent keyserver still limping around the Internet.)

But even this jumps ahead, given that the alternatives are not in fact proprietary. The list of open source tool alternatives has been the same for close to a decade now:

* For messaging/secure communication, use Signal. It’s open source.

* For file encryption, use age. It’s open source and has multiple mature implementations by well-regarded cryptographic engineers.

* For signing, use minisign, or Sigstore, or even ssh signing. All are open source.

[defanor]

> security under a hostile setting

Yes, but security usually includes availability, and I mentioned a setting with service blocking above. Like that by a government.

> (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one prominent keyserver still limping around the Internet.)

How is it a red herring?

> For messaging/secure communication, use Signal. It’s open source.

From my point of view, it is complicated by Signal being blocked here (and it being centralized helped to establish such blocking easily), likely the phone number verification won't work here, it is not available without a phone, and it is not available from F-Droid repositories on top of that. Currently money transfers are also complicated, so finding some foreign service that would help to circumvent phone number verification is also complicated, and not something I would normally do even without that. All this Internet blocking is a new development here, but such availability issues due to centralization were anticipated for a long time, and are a major motivation behind federated or distributed systems. Some mail servers are also being blocked, but generally mail still works, and less of a pain to use.

> For file encryption, use age. It’s open source and has multiple mature implementations by well-regarded cryptographic engineers.

> For signing, use minisign, or Sigstore, or even ssh signing. All are open source.

These I find to be okay. Having to install them in addition to GnuPG that is usually already available, but that is to be expected; they are available at least from Debian repositories, so not something to complain about when considering alternatives. Likewise with the key sharing: not getting to reuse OpenPGP's PKI, and will have to replace that somehow, but it is not like it is used widely and consistently anyway, so perhaps not much of a loss in practice. Likewise with familiarity of the users: I would expect a little more friction with such tools, compared to GnuPG, but not much more. And I don't see actual usage downsides apart from those. Though the benefits also seem a bit uncertain, but generally that sounds like a switch that makes sense to consider.

[athrowaway3z]

I have no clue how you reached the conclusion of calling it a red herring.

It matters - because Satan can disconnect the centralized nodes.

[woodruffw]

It’s a red herring because systems that achieve end-to-end security do so regardless of whether the underlying hosts are centralized or not. A typical network adversary wants you to downgrade the security properties of your protocol in the presence of an unreliable network, so they can pull more metadata out of you.

[Valodim]

> given that there’s only one prominent keyserver still limping around the Internet

Hey, I take issue with that. keys.openpgp.org is just about the only thing running smoothly in the openpgp ecosystem :P

[woodruffw]

Sorry, that was an unduly inflammatory framing from me. You’re right that keys.openpgp.org runs smoothly, particularly in contrast to the previous generation of SKS hosts. I don’t think it comes close to meeting the definition of a decentralized identity distribution system, however.