Show HN: Enc – A modern and friendly CLI alternative to GnuPG (github.com)
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.
56 comments
[ 3.1 ms ] story [ 129 ms ] threadI'll definitely be using this a lot. Thank you!
https://sequoia-pgp.gitlab.io/sq-user-guide/#prelude-quick-s...
I would expect a frontend to GnuPG to have a much easier adoption, since the back end would will be the trusted GnuPG.
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
* https://articles.59.ca/doku.php?id=pgpfan:tpp {The PGP Problem: A Critique}
Maybe it's a bit convoluted for interactive use at the prompt, but I actually like it.
Having a lazygit-like TUI on top of it might be a good add on?
"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`.
By that logic, you should be working out your signatures with pen and paper.
Everything done manually has the potential for errors. If something can be simplified and/or automated, it is often a huge security benefit.
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.
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.
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.
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 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...
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.
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?
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.
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.
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.
https://tests.sequoia-pgp.org/
Honestly once Sequioa finishes smartcard support and chameleon (gpg cli emulator), then GnuPG should be deprecated IMO.
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.
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.
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)
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.
Regarding “1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards”.
What is the alternative? Aren’t secrets in memory always plaintext unless you are using something external like a hardware security module chip?
Welp, my machine must be comprised, because you just described it. But you left out Age...
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.
"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.
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.
> 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.
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 :(
You are rigth though, I've added a Risks section to warn for that thingie https://github.com/spapas/etsd/blob/master/README.md#risks
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...
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.
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.
Encrypt: `age -p secrets.txt > secrets.txt.age`
Decrypt: `age -d secrets.txt.age > secrets.txt`
It asks for a password in both operations.
[0] https://github.com/FiloSottile/age