...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.
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.
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)
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.
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.
> 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.
> The PGP part of this can be replaced with NOPs and this is no less secure.
That's one of most absurd hyperbolic assertion I've had the misfortune to come across in the whole PGP debate so far. You're clearly not acquainted well-enough with how PGP is being used by linux distributions. That, or you're simply debating this subject in bad faith. Assuming the former: HTTPS is only relied upon to bootstrap keys, like pretty much every other PGP replacement you're willing to advocate for.
I know this may be painful to read for someone working on a PGP competitor, but PGP
* is a standard,
* is successful,
* is widely adopted, and
* will likely remain so for the foreseeable future.
The op and the myriad of new PGP libraries and applications that keep popping up stand testament to this. You'd probably do better to reflect on this fact than to argue and downvote a green account on an old hn thread.
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.
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.
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:
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.
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.
>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.
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.
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.
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.
60 comments
[ 2.9 ms ] story [ 74.5 ms ] threadAlthough, come to think of it, tex and its relatives (pdflatex, etc) have really quite terrible command line interfaces.
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.
Those are pretty complex tools that can do many things, so they cannot be expected to be used without learning to use them or reading the manual.
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)
Want to verify a signed file against a key that’s in another file? Nope, not supported.
Want to load a private key into a smart card without wiping the key from your keyring? Not supported.
In general, gpg has a very strong idea of how you’re supposed to use it, and it makes it very hard to do anything differently.
https://www.gnupg.org/related_software/gpgme/
It would probably make sense to implement and expose that?
Ed: see also https://wiki.gnupg.org/APIs
This makes the library really painful to use in multithreaded contexts, or when you need to have a controlled env. (like unit tests).
I use gpg-me in one of my projects, and it's very far from pleasant to use.
https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stat...
Thought the article says they're not planning to release this with v1.0
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.
Can you explain why you think it isn't?
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
The sheer volume of gpg-signed apt/rpm/tar packages downloaded and verified everyday cast doubt on your claim.
I bet the number of packages downloaded for CI alone would invalidate this claim.
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.
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.
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.
That's one of most absurd hyperbolic assertion I've had the misfortune to come across in the whole PGP debate so far. You're clearly not acquainted well-enough with how PGP is being used by linux distributions. That, or you're simply debating this subject in bad faith. Assuming the former: HTTPS is only relied upon to bootstrap keys, like pretty much every other PGP replacement you're willing to advocate for.
I know this may be painful to read for someone working on a PGP competitor, but PGP
* is a standard,
* is successful,
* is widely adopted, and
* will likely remain so for the foreseeable future.
The op and the myriad of new PGP libraries and applications that keep popping up stand testament to this. You'd probably do better to reflect on this fact than to argue and downvote a green account on an old hn thread.
Cheers.
Email is hard to secure for obvious reasons. The PGP itself is fine, even though it could be updated.
* https://articles.59.ca/doku.php?id=pgpfan:index
It turned out that PGP is not all that bad...
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.
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.
One of the options, "encrypt to an ssh key" is an interesting convenience. Since most of us already have ssh keys deployed.
https://github.com/FiloSottile/age
Everything else is either not used in practice or needs to be shifted to a dedicated protocol.
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.
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.
Those six trust levels, what were they smoking?
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.
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.
Long live GPG!