1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards
2. Binary/commits are not signed, so there is no supply chain integrity to build or install this. Readme recommends blind execution of crypto code off the internet that may or may not be what the authors actually wrote.
3. No code review seems to be happening per git history, at least no signed code review publicly accessible.
4. Breaks OpenPGP spec and conventions for seemingly no reasons at all?
5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user. (Unless you mount /proc with hidepid=2 but this is never a default and almost no one does it)
6. No support for Git, ssh, etc so you still need to use Sequoia or GnuPG anyway (as readme points out)
This seems like a really fun and educational hobby project, but I would not seriously suggest anyone use this for anything actually security critical in its current state.
To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc.
Today you can do all this with GnuPG though admittedly this is a rotting, buggy, and badly maintained c codebase. The well tested Rust replacement, Sequoia, is almost at feature parity now, so keep a close eye on that or try it today instead and see if it already meets your needs.
I wish more of these alternate CLIs could act as wrappers for GPG. I would be happy to use enc if it just called GPG cli commands (or gpg agent*) underneath to do it's tasks.
I know it's a boring to do wrappers, but I can't imagine using something that doesn't support GPG agent and YubiKeys / Smart cards. That infrastructures is why I think GnuPG is so much ahead of it's competition like Filippo Valsorda's age.
* I have an example how to use GPG-agent to decrypt and sign things, it's almost voodoo, because there is no instructions how to do it anywhere. I had to read the GnuPG's C code to understand how to do those: https://github.com/Ciantic/gpg-ed25519-to-cv25519/blob/maste...
Thanks for providing those instructions. Encryption is inherently complicated, but it seems to me that GPG is far more complicated than it should be. Extra complexity isn't just an inconvenience, it is precisely where mistakes and bugs and security breaches come from.
For example, GPG has an entire logic around photo IDs. I can see the logic of using photo ID's with some authentication mechanism, but this should be in conjunction with GPG, not built into the tool itself. GPG shouldn't have a concept of photos, it's complicated enough already. Just reading the amount of options in the man page suggests that gpg ought to be broken into smaller more easily digestible components.
So while I like to see wrappers around GPG (eg. Jason Donenfeld's `pass` password manager), I worry that the underlying complexity of GPG hides security holes that may surface in the future.
What do you mean by "encryption is inherently complicated"?
Conceptually, and thus in a cli frontend it should be pretty simple: you specify a message, a public key and a destination to encrypt, and then a ciphertext and a private key to decrypt. What is complicated?
Does it? It says how managing keys in public key cryptography is complicated. As also signing and verification, and x509 certificates rely on this then one might say they too are complicated - as is everything else that builds on asymmetric crypto. I.e why encryption specifically is complicated? (Or am I just dense and missing something? :))
The poster you replied to was clearly talking about end-to-end secure encryption being complicated. This means guarding against supply chain attacks, secure sharing of keys, verification and signatures, etc.
> Today you can do all this with GnuPG though admittedly this is a rotting, buggy, and badly maintained c codebase.
I don't understand why this would be called "rotting". Sure, it's old, but it's actively maintained by its original author, a Gmbh has been established around its maintenance and it retains a few developers for the purpose.
We do not call the Linux operating system rotting, which is a project in a similar position to gpg, nor do we call the git project rotting. All of these are old C code bases but are actively maintained. They are in c, but they've squashed a lifetime's worth of bugs. Git is notoriously bad on the command line to use, but we still use both gpg and git because they're both useful and super stable. Calling something rotting just because it's not written in Rust ignores the years and years that their maintainers have put into it.
This is to say nothing of geopolitics. It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg. Sequoia seems to be made by a foundation based in America. I doubt a significant following in Europe will pick it up.
Too often this sensitive topic is ignored, particularly with regard to encryption. Just recently gitea was taken over by an American corporation. The project was soft forked because the community was outraged. But they didn't change the license to AGPL, they just maintain the soft fork under a European company. The problem clearly isn't the license then, it's the country of origin. And that's just for source control.
Using the original gpg is a great way to show more international unity, but we all know that's a secondary reason to use software. The primary reason is that it's a quality piece of work that will be very difficult to reproduce.
GnuPG is a large C codebase and CVEs are readily found simply because of poor testing, poor abstractions, etc. C codebases are also very expensive to review for things like memory safety. As just one example I filed CVE-2018-9234 myself which allowed me to violate key usage restrictions which is pretty fundamental and just did not have a test.
Much of the core development team of GnuPG left to work on the Sequoia Rust rewrite which is IMO already much better tested than GnuPG for the features that have parity. Also, it is rust, so memory safety you mostly get for free. They even went as far as to implement three different backends for crypto primitives to easily test they all behave the same way.
> I don't understand why this would be called "rotting". Sure, it's old, but it's actively maintained by its original author, a Gmbh has been established around its maintenance and it retains a few developers for the purpose.
It is called rotting, because quite a few times critical vulnerabilities were found, but even former members of the GnuPG project could not convince Werner Koch to fix it before publication. Werner Koch also withholds updating the OpenPGP standard to make it up2date for current threatmodels. He's basically holding GnuPG hostage at that point and that threatens security. Sequoia tries to fix this, but Werner Koch does not want to change anything apparently.
> This is to say nothing of geopolitics. It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg. Sequoia seems to be made by a foundation based in America. I doubt a significant following in Europe will pick it up.
Neither the NLlabs or the p=p foundation are set in america. Both are european efforts and in part paid by the european council. This is just FUD what you are telling here.
> Using the original gpg is a great way to show more international unity, but we all know that's a secondary reason to use software. The primary reason is that it's a quality piece of work that will be very difficult to reproduce.
Well, that is the same with sequoia which is basically made mostly by europeans which make much less money than all the consultants which produce daily cloudstuff which does not generate any value for society than taxes. to be honest, you should get your facts straight before telling FUD about seqouia.
> It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg.
Nitpicking but I think you got this part the wrong way around. The US had export restrictions on encryption including PGP so Europe had to create their own.
> 5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user.
Not to mention that the password will also get stored in plaintext in the shell's history file if the shell is in interactive mode.
> To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc.
But SSH now supports U2F for any FIDO or FIDO2 security key AFAICT (no need to specifically a Yubikey 5 or Nitrokey 3): it's unrelated to GPG.
Isn't it better to directly use this new SSH functionality inside of using the more complicated GnuPG+SSH thing? (I'm asking: I've got no clue how the later works).
Any thoughts/explanation on this is most welcome.
> (Unless you mount /proc with hidepid=2 but this is never a default and almost no one does it)
Ah! I do it on all my systems! (not that it'd be a reason to have passwords in plaintext everywhere)
> Isn't it better to directly use this new SSH functionality inside of using the more complicated GnuPG+SSH thing? (I'm asking: I've got no clue how the later works).
If the only thing you need from a smartcard is ssh, and you do not need to convince others your public key is really yours, then FIDO2 ssh is great.
That said, if someone is to add my key to their server, exporting my ssh key from my published, and well signed PGP keychain is the easiest way to form trust they got the correct key.
Also you cannot do things like file decryption or signed commits with a fido2 device. Since virtually every developer (imo) needs those coming from a hardware anchor, and they require PGP, might as well use one spec that does everything and publishes one public keychain for others to trust.
> To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc.
Welp, my machine must be comprised, because you just described it. But you left out Age...
Age is actually -worse- than enc by pretty much all the same criteria I outlined.
Working with established interoperable standards and conventions for hardware support, software support, key discovery, and supply chain integrity and implementing them well with careful team code review and extensive compatibility test suite is the hard but necessary road in security.
Age does not even attempt to do any of this, and IMO only has very niche use cases, if any, compared to a reasonable OpenPGP spec implementation like Sequoia.
1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards
2. Binary/commits are not signed, so there is no supply chain integrity to build or install this. Readme recommends blind execution of crypto code off the internet that may or may not be what the authors actually wrote.
3. No code review seems to be happening per git history, at least no signed code review publicly accessible.
4. Breaks OpenPGP spec and conventions for seemingly no reasons at all?
5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user. (Unless you mount /proc with hidepid=2 but this is never a default and almost no one does it)
6. No support for Git, ssh, etc so you still need to use Sequoia or GnuPG anyway (as readme points out)
This seems like a really fun and educational hobby project, but I would not seriously suggest anyone use this for anything actually security critical in its current state.
To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc.
Today you can do all this with GnuPG though admittedly this is a rotting, buggy, and badly maintained c codebase. The well tested Rust replacement, Sequoia, is almost at feature parity now, so keep a close eye on that or try it today instead and see if it already meets your needs.