OpenPGP in Rust: The Sequoia Project(lwn.net)
lwn.net
OpenPGP in Rust: The Sequoia Project
https://lwn.net/SubscriberLink/830902/b751810a99460a39/
58 comments
...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?)
Second to openssl? I would rank gpg as the worst by a considerable margin.
Although, come to think of it, tex and its relatives (pdflatex, etc) have really quite terrible command line interfaces.
Although, come to think of it, tex and its relatives (pdflatex, etc) have really quite terrible command line interfaces.
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.
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.
ffmpeg is pretty nasty as well, and I don't have much fondness for ImageMagick's command line either.
They are both old and really complex tools, that explains part of it.
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
Agreed, I'm not sure what's wrong with openssl's cli and git's cli (I do agree gpg's sucks).
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.
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.
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)
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)
Except that gpg also fails to make the hard things possible.
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.
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.
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.
You can see the help for the proposed `sq` command line interface here:
https://docs.sequoia-pgp.org/sq/index.html
Thought the article says they're not planning to release this with v1.0
Thought the article says they're not planning to release this with v1.0
There already is a gpg Api - gpg me (made easy):
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
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
No, this is not a very good suggestion. gpg-me just wraps the gpg binary and relies on a lot of global state, environmental variables for example.
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.
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.
[deleted]
There is a proposal for a "stateless command-line interface for dealing with OpenPGP messages" that Daniel Kahn Gillmor brought to the IETF:
https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stat...
https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stat...
Looks like it expired on September 7th. Does that mean it's not being considered?
I think a good balance between ease and options would be important for a crypto tool. The nicer it is the more people will use it.
The git command line is very good actually, and constantly improving.
mkisofs wins the trophy imho.
Have you ever used tab auto-completion before? GPG's CLI is actually pretty intuitive and self-explanatory. You can also type:
gpg --help
man gpgAll 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.
I wish Autocrypt(.org) would be PGP's future. Zero conf, only syncing keys between devices is something you'd have to do manually.
Those six trust levels, what were they smoking?
Those six trust levels, what were they smoking?
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.
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.
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.
Alternatively: https://github.com/str4d/rage
Kind of lacks any sort of OpenPGP compatibility...
Thats the point. PGP isn’t a good standard.
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.
PGP is a giant blob of byzantine implementation details and layers of accrued crust that people call a standard by convention and out of inertia.
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.
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'.
I think it's an excellent standard and its widespread adoption demonstrates this.
Can you explain why you think it isn't?
Can you explain why you think it isn't?
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.
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
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.
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.
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.
> It has virtually no adoption.
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.
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.
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.
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.
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.
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.
If a modern alternative existed, it would have been invented.
Email is hard to secure for obvious reasons. The PGP itself is fine, even though it could be updated.
Email is hard to secure for obvious reasons. The PGP itself is fine, even though it could be updated.
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:
* https://articles.59.ca/doku.php?id=pgpfan:index
It turned out that PGP is not all that bad...
* https://articles.59.ca/doku.php?id=pgpfan:index
It turned out that PGP is not all that bad...
It's impressive as a character study of 'PGP Fan', it's not much of a technical rebuttal of critiques of PGP.
Getting downvoted but that looks like a cool tool, and I didn't know about it, so thanks.
One of the options, "encrypt to an ssh key" is an interesting convenience. Since most of us already have ssh keys deployed.
One of the options, "encrypt to an ssh key" is an interesting convenience. Since most of us already have ssh keys deployed.
>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.
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.
Why? PGP needs to be deprecated in favor of things like AGE and Magic Wormhole.
https://github.com/FiloSottile/age
https://github.com/FiloSottile/age
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?
age only covers authenticated encryption. minisign/signify covers the signing part.
Everything else is either not used in practice or needs to be shifted to a dedicated protocol.
Everything else is either not used in practice or needs to be shifted to a dedicated protocol.
Magic wormhole still doesn't have an easy way to run on windows, i have to download a 2.4GB VC Build tools with a shitty installer from Microsoft.
There's a Magic Wormhole implementation in Go that ships windows binaries: https://github.com/psanford/wormhole-william
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.
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.
The problem with the idea that PGP is battletested is that it lost all the battles and learned nothing from them.
Ahh the unending saga of people too lazy to read some GPG man pages and proposing unfitting replacements.
Long live GPG!
Long live GPG!