...I really don't want to sound entitled, but while you're at it, could you please only keep the old CLI for compatibility purposes and come up with something that can actually be used? GPG's command line is second only to the one of openssl. And maybe git. It would really help adoption if usability was improved. Having an API instead of just CLI might also help (doesn't Enigmail just run the binary?)
Importing and managing keys and encrypting messages is something I do via CLI because it is easier to do what I mean, not what some developer thinks I mean. The CLI is more expressive and I don't think to the detriment of usability.
It's just for most people, they're not used to working with a tool that merges communication and text processing with a CLI interface.
At least ffmpeg makes it easy to do the very easiest thing. I don't have to look up this one:
ffmpeg -i input.file output.file
Now, usually I want to do something more complicated, so I end up having to look it up, but it's hardly the ffmpeg folks' fault that audio and video encoding is such an ungodly mess of different containers and encodings; while it could be better, I think most of its complexity is inherent to the problems it's trying to solve. I do think there's an argument that it tries to do too much, and the complexity could be mitigated if it were split into several smaller tools and a wrapper for the most common commands, like apt.
I think the mantra of "Make simple things easy and hard things possible" applies here. These tools all do a poor job of the former.
Now, if you're writing a low-level tool (in git's terminology, plumbing), that doesn't matter as much, because it's designed to be wrapped; maintainability and (interface) stability probably take priority over being maximally intuitive. But if you're writing a tool for end users (including developers), some focus on UX is warranted.
(How much each of these tools are intended for end users, can be argued separately, not by me)
I dunno, Openssl CLI is one hairy beast. To be honest I don't really know the best solution to such problems. Smaller, more specialized binaries? I mean, s_client is so vastly different than say, rsa.
All of my friends who work in crypto loathe PGP. None of them mention the implementation as their primary area of concern. Some of them mention the implementation as an unsurprising sequela to the kitchen sink of “capabilities” PGP attempts to cover. It has, by design, a nearly fractal surface area for users to compromise their security and for developers to make subtle implementation errors.
If you want to do store and forward messaging on a federated network then PGP is pretty much it.
So if all those cryptographers don't like it then they should design something better. It is unlikely they will be able to come up with something simpler.
The fractal surface area of PGP is why it has continued to enjoy such widespread adoption. People need to secure their messages and other systems are far too ridged or specialized for their needs.
Is PGP/GnuPG's horable to use or develop for? Absolutely. However, unless your friends are willing to step up and build something that's flexible enough to cover all our usecases, PGP will continue to see adoption and projects like this will continue to pop up.
Age/Rage is not a standard at all. It is just a program. It definitely has nothing to do with a project intended to implement a particular standard. It is a non-sequitor here.
Being a giant blob of byzantine implementation details and layers of accrued crust doesn't take away from PGP being a standard. Take a look at BMP or Postscript/PDF or even Email and tell me they're not the same.
Parent's point still stands: PGP is a standard (with widespread adoption, mind you) whereas Age is not. Whether it is a good standard or not depends on how you're using it.
The parent's point was that age is 'just a program' and thus not a standard, with no mention of adoption. But PGP is arguably less of a standard than age, by that metric. As to adoption, PGP has very little adoption for actually securing anything (rather than performative use) and for those uses it's trivially replaceable because it's not actually good at them - that's pretty much the motivation behind things like 'age'.
It has virtually no adoption. Every modern secure messenger application sends encrypts more messages, and between more pairs of people, than OpenPGP has in its entire lifetime.
Messaging and email are different applications. People use messaging apps because of the rise of the mobile devices, not because these messaging apps use forward secrecy or ECC. Don’t try to link that adoption to crypto protocols!
Also, very few of these users actually use secure versions such as signal or wire. They all happily post on Facebook‘s messenger and WhatsApp and don’t care about crypto.
Messaging applications use protocols derived from Signal Protocol rather than PGP because they had the opportunity to do something better than PGP. The first secure messengers did use PGP; designing a new messenger based on PGP would be malpractice.
WhatsApp uses Signal Protocol, and protects many order of magnitude more messages every day --- or, if you like, bytes of plaintext --- than PGP ever has or will.
Email not being a messaging protocol is... a take.
That article was actually the motivation behind my serious of PGP fan articles. I wondered what the opposite would look like, completely partisan, rabidly pro-PGP:
They would not; you're either drastically underestimating the number of messages modern secure messengers handle, or overestimating the number of packages verified every day. But PGP is also an archaic way to sign packages, and there is no network effect to package signature schemes; all of them can, and should, be replaced with modern schemes like minisign/signify.
Our disagreement here is on your claim that PGP has virtually no adoption. I brought up the monstrous amount of packages that get verified by CI/containers/OSs as an example where PGP is widely adopted. No one is claiming that dedicated tools can't do the job better.
People use PGP because it is standard, widely-adopted, and does what people need it to do. From where I'm standing, people who argue against these three facts are underestimating PGP or overestimating their own favored solutions.
No, people use PGP because at the times these systems were designed, there weren't better options; in some cases, there literally wasn't materially better cryptography, and in others, the better cryptography wasn't suitably enabled by good libraries. None of that is true anymore, nobody should be using the archaic PGP format for anything new, and, in most cases, people should be investigating how to replace PGP with modern alternatives.
This discussion was about your false assertion that PGP "has virtually no adoption".
If you want to change our discussion to be about replacing PGP instead, then I completely agree that people should replace PGP with modern properly-standardized alternatives if such exist.
Fundamentally, the discussion is about your (and others') claims that PGP is some key part of security infrastructure and that its wide adoption and importance in such infrastructure shows that. It probably got a little stuck on broad terms like 'adoption' and 'standard' instead of looking more specifically at the type of use you're holding up as an example.
Here's what happens in the super-common, basic case of 'installing a third party (i.e. not from the distro repos) package on some debiansy Linux':
You access the the developer's webpage (via a browser and https) and read the installation instructions. They tell you to curl in (over https) some pgp key and some (https) endpoints for finding and downloading the package.
You apt-whatever and the package is installed.
The PGP part of this can be replaced with NOPs and this is no less secure. All the heavy lifting here is done elsewhere using infrastructure that actually has wide adoption and standardization and does useful things.
Nobody in this thread is working on a PGP competitor, nor is it acceptable on HN to allege that people are commenting in bad faith the way you just did. Please revisit the guidelines. If your arguments were sound, you wouldn't need to resort to personal attacks. Shore them up.
I don't understand most of this comment but I suppose at least we've come to agree that you can replace PGP with anything (like a NOP) in this particular use case.
>Conceptually, Sequoia takes an identity-based approach to its public keyrings, where the keyring is designed to be "more like a per-domain address book than a PGP keyring."
I think this is the future for encrypted messaging of all types. Ultimately the user needs some sort of conceptual model that will allow them to do reasonable things. Making the identity a thing in and of itself removes a lot of unneeded conceptual overhead.
That is as opposed to the current practice of simply ignoring the identity issue and leaving the whole thing as a responsibility that the user has no idea of how to deal with.
If PGP is actually a bad standard from the crypto point of view I can only wonder why people downvote this and insist on supporting garbage and even rewriting it in Rust. But I'm not educated in these matters, so: what's exactly the problem with PGP/Seqouia and why age/rage are better? Can all PGP usecases be covered by age?
Once there's a verified and tested v1 then you can start talking about deprecation. It's still beta software. Do you really think you're going to convince an enterprise or anything security critical by going "deprecate your battle-tested protocols and applications for this beta tool!".
There isn't even an explanation on that page of why it was written, why it should (or could) replace OpenPGP, how to replace it ( a handy comparison table), and which use cases the tool is good for. It'd be really great if instead of pushing for change, you'd actually provide some context and explanation.
Everybody can scream for change, few can understand (much less explain) the why and how. Maybe try and join the latter.
