Ask HN: CLI Tool for File Encryption?

25 points by e12e ↗ HN
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

[2] https://github.com/FiloSottile/age

[3] https://gnupg.org/

[4] https://wiki.openssl.org/index.php/Enc

35 comments

[ 3.4 ms ] story [ 91.7 ms ] thread
Have you looked into rclone?
When I want symmetric-key encryption which can even be opened by average Windows user, I just use `7z a output-file.7z input-file.txt -p"password"`
Hello! age (https://age-encryption.org) author here. Different tools can definitely be better for different use cases (for example I am a fan of restic [0] for backups, although age is designed to compose well with tar, if that's your thing), but do you mind me asking what made that tool feel more well defined than 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

I may have been too quick to judge - I first thought sigtool was a superset of openbsd signify - not a work-a-like. And it appeared sigtool's approach with probuf was somewhat sturdier than a custom spec/format (although the age spec does look quite nice and straightforward). Additionally, I came across some comments on age's custom primitives - but I suppose that's also similar for the two.

Ed: thank you for your work on age!

Are you planning to support hardware encryption tokens also like GPG does with OpenPGP cards?

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.

Yes! That’s what the plugin system is designed for. https://github.com/str4d/age-plugin-yubikey is fairly mature and I use it every day.

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!

Interesting, when I looked at it a couple years ago I didn't see that. So it uses the PIV mode? And it can use asymmetric encryption as I see it?

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.

https://github.com/FiloSottile/passage :)

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.

This looks great, thanks! Yeah it will need a community solution, the one on Android for pass/gpg is also not from the original makers of either! It actually took a long time for this toolchain to materialise on Android too.

Thank you for considering this usecase which I personally find very important (though I know it's kinda a niche all things considered!).

> 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.

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...

age is the one thing that has any degree of mindshare. Technically it is certainly good enough for ensuring confidentiality. There are gazillion somewhat similar also-ran encryption tools, but their benefits are not there compared to their relative obscurity
Not sure what is implied specifically by "modern" outside of library's age, but it is really hard to beat setup of Yubikey's with OpenPGP and bash scripts using luks or tar depending on encrypted files use case.
I wrote an article about OpenSSL some time ago, and it's Google's top hit on "openssl flat file encryption."

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...

Heh, a problem we honestly have with age is that the whole article (including SSH key support!) would be a one-liner with age, so it just doesn't get written and it doesn't get SEO :)

It's a good problem to have, but I find it funny.

I've been thinking about what my job would be like on the morning of a ransomware outbreak.

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).

Not sure if you are looking to single-file backups or an actual backup solution that includes good encryption. I have very good experience with restic (https://restic.net/), which encrypts all backups and does deduplication, using it on production servers with millions of files, as well as for home use (rather 100k files order of magnitude). It would be a bit too cumbersome for single-file use, though.
You have to be careful with unknown scripts/apps on GitHub.

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!

(comment deleted)
If I need to encrypt a file for quick sharing, I’ll use gpg. Encrypt: gpg -c file.zip

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.

Thank you everyone for your input. My use-case for simple cli encryption is mostly for single files - not part of a full backup solution (for that I'm leaning towards zfs send with encrypted file systems).

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.

If you want backups, Restic or Borg. I use Restic.

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!

> If you want backups, Restic or Borg.

This. Backup is too important to make the mistake of rolling your own.

For me GPG is still the #1.

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.

(comment deleted)
Many interesting comments in this thread -- thanks, everyone!

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?