Enc is a CLI tool for encryption, a modern and friendly alternative to GnuPG. It is easy to use, secure by default and can encrypt and decrypt files using password or encryption keys, manage and download keys, and sign data. Our goal was to make encryption available to all engineers without the need to learn a lot of new words, concepts, and commands. It is the most beginner-friendly CLI tool for encryption, and keeping it that way is our top priority.
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.
For anybody that still believes in gpg and is interested in using it to transmit data across his organisation we've built https://github.com/spapas/etsd.
This is a project that holds the hands of the users of an organisation to help them send gpg encrypted messages. We're using it successfully for almost a year.
This looks very nice. Unfortunately, I think you overstate the security slightly:
> After the public key is approved the authority can receive data. The data is encrypted with its public key using OpenPGP.js on the client side and only the cipher (not the original data) is saved to the server. Since the original data never reaches the server we can be sure that even if the server was compromised somehow no sensitive data would be breached.
The server could deliver a backdoor in the client code, no? So it should be quite possible for a hacked/malicious server to steal a user's private key on next use (after breach) of the service?
This isn't a critique of the architecture per se (if upstream is compromised, client compromise is always a risk) - more that it is important to be precise in declaring risks.
Yes, you are right on that. If the server is compromised a malicious user may change the client-side code to add a backdoor and steal your private key when you unlock it. He'll be able to steal only the keys that are unlocked while the backdoor stays undetected (not all the data).
The ideal way to resolve that would be to change the service to an API and offer binaries with a correct signature so the user can check and make sure that they get the correct thing. Actually I tried writing the client binaries using electron (https://github.com/spapas/etsd/tree/master/client) but didn't have the time for that :(
"Easy installation. Grab the binary and you're ready to go." Is putting the binary in the PATH really more user friendly than what's available in the package manager? Security updates and so on seems like a nightmare with that setup, and for something this important not an option for me.
Since your target audience are people who can't wrap their heads around normal gpg can you expect them to know what the PATH is and how to figure it out? My first months on linux I didn't know what it was.
Reading through the README I don't really understand what is supposed to be easier compared to GnuPG. First I thought it could be verbosity but GnuPG has -d/-e flags if you prefer. Some comparisons could be useful I'm probably missing something.
That said I don't think encryption intended for engineers should be simplified, if they don't understand what they're doing it's a footgun. Do you want users asking you to recover their private keys? Instead of hiding the "words, concepts and commands" try to make them easier to understand.
Also, you have a typo on #4, `env version` should be `enc`.
You're missing my point. I'm not saying it should be difficult either, but is GnuPG really that difficult? Is --sign/--verify, --encrypt/--decrypt overly complex, and how does this tool improve on that? Should the users understand when to use symmetric vs asymmetric encryption? Is it important to know the difference between public and private keys?
I just fail to see where and how this tool improves, what steps are removed compared to the flags I listed? Is it the lack of dashes? The pen and paper straw man doesn't answer my questions.
> The pen and paper straw man doesn't answer my questions.
I quoted the part of your comment I replied to. That part was no question. It was the claim that cryptography should not be made simpler. I strongly disagree with that point.
That has nothing to do with the specific tool at hand. It is irrelevant how and whether it simplifies things, if you claim that the premise is wrong.
> I quoted the part of your comment I replied to. That part was no question.
You did, but the next sentence you conveniently left out however is a question: "Do you want users asking you to recover their private keys?"
Together in their context they make my point. The so called complexity is a result of the features. If you want simple E2EE chat-like encryption you can have that, but then you need to manage your users keys and so on. And that's a valid use, but is it for engineers? As soon as functionality other than simple E2EE enters the picture explaining the concepts becomes a necessity.
To put it another way, I don't think it can be simplified without sacrificing security (for the user and their data) or features. It is important to understand how it works, but not necessarily being able to explain the algorithms.
The importing of public keys via github/gitlab is a neat thing! Can that be used to also encrypt messages using SSH public keys? Generally, I it's unclear to me how secure the code is written/audited and don't see any benefit over using age for symmetric encryption, though.
What I really want in an encryption tool is something that I can throw on a thumb drive (portable), lets me encrypt a single file, which I can then decrypt when I get to another machine (windows mac or linux) with nothing more than a password. without having to install any additional software/drivers on that new machine, and without needing admin rights. I'd happily keep binaries for each OS on the drive as long as any one of them could decrypt the same file.
I'm not moving state secrets around, but it'd be nice to have certain files I carry with me protected in case I lose the drive, but still have them easily accessible on whatever machine I'm sitting in front of.
As much as I appreciate the efforts, considering how central GnuPG is nowadays, an alternative has a long way to go before it reaches consensus in the industry.
I would expect a frontend to GnuPG to have a much easier adoption, since the back end would will be the trusted GnuPG.
This claims to be well-documented and secure by default, but I cannot find a link to the documentation (or is it just the README)? What actual algorithm is used for encryption and for signing?
The README has a major red flag:
> From the math perspective, there is no difference between private and public keys, they both can be used to encrypt messages that only can de be decrypted by the other. Most of the security tools, including enc, artificially forbid using the public key for decrypting messages because that's not how it should be used (encrypting messages that anyone can decrypt is pointless).
Most security tools forbid that because it is dangerous! Also, this description sounds like textbook RSA is being used...
This is beautiful, and I love your readme. I've been wanting to make something exactly like this for a long time but unfortunately never got around to it.
GnuPG is a faithful implementation of OpenPGG, a protocol has been heavily scrutinized. It hasn’t had many CVEs (similar number to SSH and OpenVPN). So I trust this software. The command line is easy enough. The newer versions provide AEAD ciphers, and the software is well supported and maintained.
There is some complexity in the man page with many flags, the documentation and the OpenPGP packet format. The KDF is not modern, and old ciphers are still supported. Other than than that, it’s fine.
"Enc is a CLI tool for encryption, a modern and friendly alternative to GnuPG. It is easy to use, secure by default and can encrypt and decrypt files using password or encryption keys, manage and download keys, and sign data."
If you read further you discover it is using a go implementation of openpgp to do it's job.
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.