Ask HN: CLI Tool for File Encryption?
I recently came across sigtool[1] which on the surface looks like a slightly more well defined tool/format for encryption than age[2].
And they both attempt to be simpler, more modern than gnupg[3] and easier to use than eg: openssl[4].
Which tool do you use/recommend for encrypting files, and why?
My primary use case is for backups - but interested in other use-cases as well.
[1] https://github.com/opencoff/sigtool
35 comments
[ 3.4 ms ] story [ 91.7 ms ] thread[1] https://github.com/FiloSottile/age
age has a stable spec [1] and an alternative implementation in Rust [2] based on the spec with extensive interop tests.
If that’s just not visible, I’d be interested in how to fix that appearance, too!
[0]: https://words.filippo.io/restic-cryptography/
[1]: https://age-encryption.org/v1
[2]: https://github.com/str4d/rage
Ed: thank you for your work on age!
For me this is an absolute must-have in order to even consider age as an alternative for GPG/PGP. GPG's codebase is not great indeed, but in this case it's not super important as the key generation happens inside the actual token anyway.
Currently it's only compatible with https://github.com/str4d/rage, because age only supports plugins in a branch, but I'm hoping to land support this week!
This is definitely something I will look at. One problem is that I use Unix Pass ( https://www.passwordstore.org/ ), which uses GPG under the hood. Through that I use the yubikeys as the actual encryption source for each password, I have each password encrypted against multiple keys to safeguard against loss.
So what would be needed for me to completely move over to age, would be a version of 'pass' that supports age with yubikeys, and also a mobile app that can do this (right now I use PasswordStore on Android, which communicates with OpenKeyChain which is basically GPG for Android with a nice shell around it). So I use the Yubikey over NFC there (though USB is also possible if you really want), to access my passwords. It works pretty well after some initial hiccups.
Besides this I GPG for asymmetric-based file encryption of things like backups, for which age could already be an alternative indeed. And for SSH access, but I kinda had Fido2 pegged as a replacement for that as this is where they're seeming to be headed.
That's exactly the use case I set out to replace for myself. I'll put together a guide at some point. The part I don't use and so can't really own is the mobile app, I would love a community solution there.
I am also planning to integrate https://github.com/FiloSottile/yubikey-agent which makes the SSH authentication part very easy, so that you only type your PIN once and it stays cached.
Thank you for considering this usecase which I personally find very important (though I know it's kinda a niche all things considered!).
The age plugin system and its currently-specified IPC [0] focuses on easy interoperability via plugin discovery in the PATH. This works very well for native desktop applications (and even between e.g. a Windows host and WSL guest [1]), but obviously not for web or mobile. I'm not optimistic about dynamic plugin discovery ever being feasible for web, but in theory alternate plugin-discovery mechanisms could be figured out for mobile (e.g. Android Intents).
Fortunately, the age plugin system is _also_ a relatively thin wrapper around the core age concepts of Recipients and Identities, so it's possible to write code for an age plugin that can also be used directly as a library! I haven't tried this with age-plugin-yubikey yet specifically, but it should be possible (after some refactoring) to produce a library that can be used to statically include support for YubiKeys directly in an age mobile app, backed by whatever Android library is currently used to provide YubiKey PIV access.
[0] https://github.com/C2SP/C2SP/pull/5
[1] https://github.com/str4d/age-plugin-yubikey#windows-subsyste...
Currently it's only compatible with https://github.com/str4d/rage, because age only supports plugins in a branch, but I'm hoping to land support this week!
I've heard great criticism of directly using the RSA functions, but they do work for the exchange of a very small amount of data.
Newer versions of OpenSSL offer chacha20-poly1305 in the "enc" symmetric ciphers.
https://www.linuxjournal.com/content/flat-file-encryption-op...
I use p7zip for encrypted backups, even though the AES implementation is far from best practice.
https://piunikaweb.com/2019/02/01/insecure-aes-crypto-implem...
It's a good problem to have, but I find it funny.
I think that I'd be asked a set of questions:
- Do you have offline/airgapped backup media?
- Do you have signed sha256 signatures that can verify the backups?
- Do you have secure systems and spare media to make copies of these backups?
Does your tool do all of this? Also, do you use AEAD ciphers without separate MACs?
We have a lot of HP iLO, and when those get infected the server needs to be junked (I don't know any way to remove iLO malware). I'd actually prefer something where the Intel ME is completely disabled, just to be safe (time to dig up a Core 2 Duo).
They may not be reviewed, may disappear or not maintained next year, file formats might be specific or not supported by other tools. The benefits are also dubious over well established tools like OpenSSL (if you just want to encrypt a file from command line).
Use widely-used well-known tools. File encryption is a commodity!
Decrypt: gpg file.zip.gpg
However, for my personal files on my computer, I use a Veracrypt container with a strong password and custom pin.
This is more of a one-off tar czf - $HOME | encrypt > /mnt/usbstick.tgz.enc type thing - or for sharing encrypted files.
But I agree 7zip is a decent option for the latter.
https://blogs.sap.com/2022/04/23/how-to-encrypt-and-decrypt-...
For anything critical, I try to avoid tools that are neat/cool but developed by small teams or individuals where the maintenance could suddenly disappear, which is common.
https://nuetzlich.net/gocryptfs/quickstart/
If you want file encryption, gpg -c (AES 256) or gpg -e (cv25519, optionally signed with ed25519). Frankly, there are tons of choices for file encryption.
If you want file system encryption, ZFS native encryption. There is fscrypt for other Linux file systems, but it doesn’t support authenticated encryption AFAIK.
If you want disk encryption, LUKS. Better yet, use file system encryption with a better mode and authenticated encryption.
If you want per file encryption of a directory, consider rclone which uses secret box from NACL (or gocryptfs which uses OpenSSL). There are many other options such as cryptomator (written in Java), but I can’t confirm them!
This. Backup is too important to make the mistake of rolling your own.
The main reason is the ability to use physical smartcards for encryption (or the openPGP applet on a yubikey). Until 'age' can match that, it is no alternative for me.
But a related question: how to handle long-term usage?
I mean, I had some scripts which were essentially using "openssl enc -bf -salt" and this has worked fine for more than a decade. But at some point (I think when OpenSSL went from 1.1.0 to 1.1.1), OpenSSL started generating a warning about "deprecated key derivation" and suggesting "using -iter or -pbkdf2". Now, I can obviously update the scripts, but then the need to start storing metadata arises: this file was encrypted with this method, but this one with the other method.
I am confident that such issues arise with any long-running process. How to cope with the issue?
http://ccrypt.sourceforge.net/
https://github.com/nodesocket/cryptr