Age: A simple, modern and secure file encryption tool (opens in new tab)

This is great, it fills a gap that I've long defended as PGP's remaining legitimate use case. Of course, now we just need to work on the adoption problem. Despite the fact that PGP adoption is a well-known joke in itself, all the tools designed to replace it (with the exception of the IM space) have somehow managed to achieve even lower use rates.

It's been almost five years since Magic Wormhole first released, and about half a year since that popular Latacora post recommended it for transferring files, and said "Someone stick a Windows installer on a Go or Rust implementation of Magic Wormhole right away". Guess what you're still not going to find a reliable Windows build (let alone a GUI) for? Yep that's right. Despite the fact that most of these projects come from a felt need for better alternatives to PGP for the average user, very few of them have actually come up with a product that's more accessible to the average person.

NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa...).

There are applications where the extra time and space of something like ed448 present uncomfortable trade-offs.

File encryption is not generally one of those applications.

So I find this a little disappointing.

But I suppose that NIST PQ will finalize in the not far future and this will get replaced by something that hybridizes with a PQ scheme. (I say replace because the expectation that a pubkey is something you can easily copy and paste doesn't really work with the PQ schemes you'd likely use with file encryption.)

What happens if auth fails part way through the file? Do you get a truncated decryption on stdout? -- or is this buffering the whole input in memory?

Some questions about the spec:

1. How does age disambiguate between filenames and other key formats for the -r argument? (Those formats are also valid filenames)

2. Does the header use normal Base64 (i.e. +/) or url-safe Base64 (i.e. -_). The specification sounds like normal Base64, but some lines of the example contain -_ others contain +.

3. What characters are allowed in the header? ASCII only? (the current key-formats are ASCII only, but an implementation is supposed to skip unknown formats)

4. Are any characters forbidden in recipient types, arguments and additional lines?

5. Which strings at the beginning of a header line have special meaning and thus are illegal for additional lines? Only `-> ` and `--- `? I assume the space is mandatory in those strings despite the spec not mentioning that for `->`?

6. CRLF normalization of the header is only mentioned in the section about ascii-armored files. I assume it also applies to non ASCII armored files?

7. Is keeping the public key secret to achieve symmetric authenticated encryption an officially supported/recommended use-case?

(If the public key is public, the MACs block decryption oracles. However they don't provide any authentication, because the message isn't bound to any sender and thus an attacker can just encrypt their own message to your public key. If the receiver's public key is secret, this isn't possible and thus the current implementation provides symmetric sender authentication)

8. How does the command line tool signal failure/truncation/corruption?

Is there a detailed description of the security goals and crypto rationale anywhere?

For example, it seems that if you use scrypt then you get fully authenticated encryption: the message must have come from somebody who knows the password (either a trusted user or you chose a weak password). But if you use X25519 then the scheme used is ECIES, so no sender authentication, only IND-CCA security.

The format document says that if you want “signing“ then use minisign/signify, but I suspect most people want origin authentication. We know that it is actually quite hard to obtain public key authenticated encryption [1] from generic composition of signatures and encryption, with many subtle details. It would be better if age supported this directly for X25519 as it does for scrypt. Unfortunately, you can’t simply use a static key pair to achieve this (as in nacl’s box) as age uses a zero nonce to encrypt the file key with chacha20-poly1305 so reusing a static key will result in nonce reuse. (This seems a bit fragile).

[1]: https://eprint.iacr.org/2001/079

"it looks like we'll be ok" remains their status on the problem of whether it's fine to just take SSH keys and use them for something quite different.

That's just not good enough. It was fine in early drafts because there was hope they'd remember that "Solve all of the world's problems" was not their goal, and so SSH keys might be irrelevant in later revisions anyway. It's not fine in something intended to actually ship.

Either get somebody to put lots of work in to verify that yes, it's definitely safe to do this as SSH stands today, and contact SecSH WG or Sec Dispatch or whoever to make sure they know you're doing this now - or, as seems much more likely, rip out all the SSH key code and highlight that line about how you don't want to do key distribution in age because it's hard.

PGP is full of things its creators thought might be safe that you now have to tell people not to do because it turns out they're unsafe. This tool should not recapitulate their mistake.

Rust implementation: https://github.com/str4d/rage

This looks really good, I've used ccrypt (#1) for years as a simple Unix-y encryption tool to avoid the complexity of GPG (though this is symmetric encryption only so you need to have a secure way to exchange keys).

I just added a pull-request to allow the recipients flag to also be specified as a https:// or file:// URL - this is mostly useful to use the GitHub <user>.keys endpoint to grab user keys eg.

  ./age -a -r https://github.com/<user>.keys < secret

will encrypt using <user>'s GitHub SSH public keys.

#1 http://ccrypt.sourceforge.net

#2 https://github.com/FiloSottile/age/pull/43

Not that it matters, but age hasn't hit 1.0 yet. (Close, though!)

With that in mind, it's still really exciting. I can't wait until I never have to use GPG ever, ever again.

What problem is this solving that isn't already done by other tools?

Age looks somewhat promising, but I am still looking for a reasonable alternative to TrueCrypt. Encryption should be as easy as possible. The process of gathering your files (plural!), put them into a folder, zip or tar that folder and then encrypt it, to delete the remaining files afterwards, is anything but not easy. Adding new files is even more horrible. TrueCrypt was so easy, just select the encrypted file, enter your password and voila, you got a volume mounted where you can easily add or remove many files. I know that Veracrypt exists, but it does not feel like a solution for the next decade(s).

Its super weird. There is this use case to de/encrypt a single file, but mass storage of files in a secure way and without a proprietary protocol seems impossible.

This is neat. A quick browse through the code, looks like it uses DJB's chacha and polyxxx underneath.

I've been waiting for a worthy replacement for "crypt" for a very long time, and gpg, while it can be coaxed into doing that with much effort has simply become a bloated abomination at this point.

Hope this gets vetted by the crypto community and gains popularity.

So the modern alternative would be this for file encryption, and signify for signing. What's the consensus on an alternative for GPG authenticating?

And what are the expert opinions on themis: https://github.com/cossacklabs/themis ?

We need a protocol/scheme that other things can adopt much more than a tool. There will always be a reason why someone can't use a tool,but with an encoding/scheme/protocol you can push for different things to use it.

To give an example, I was in a work situation more than once where an external party wanted to transfer files to or from our company and I was suppose to help find a standard tool/method. The only (and I mean only) way right now is pgp due to it's ubiquity with s/mime on email being second. We do need great tools like this but we need them to where if I can't use it due to license,policy,etc... Issues i can use a separate compatible tool.

So, My only suggestion to the author is to please make a fixed and versioned standard out of the scheme.

I once made something similar after reading a blog post here on HN [1] just to see how easy it is to make something like this. Mine [2] uses passphrases to generate keys with the Argon2 algorithm and then uses NaCl's secretbox for encryption. I also made a version for use on streams. It's not up to snuff for industrial use, but it's really easy to use if you just want to encrypt some files with a password and also very simple if you want to modify it for your own purposes.

[1] https://blog.gtank.cc/modern-alternatives-to-pgp/

[2] https://stutonk.github.io/crypt.html

A tool/protocol is as secure as the people using it.

I found that when working with non-techies that 7Zip is an acceptable encryption tool. It used proper encryption, it's open source, available on all platforms, available with GUI and CLI.

> Out of scope:

> The web of trust, or key distribution really

Is there anything in the tptacek suite of replacement tools for this? Like Keybase but fully open source and/or decentralized?

For encrypting text files, I just use vim's `:X` command and enter a pass phrase. Simple, easy, portable, works everywhere. I have configured my .vimrc to `set cryptmethod=blowfish2` and disable backup/swap files for encrypted files. Are there any issues with this? Is there any other option that will work on virtually all UNIX devices without installing anything additional?

I normally use scrypt (with passphrase) for file encryption for personal backups.. age isn't competing with this use case i take it?

I'm not a big fan of tools that take encrypted data, and decrypt it by creating a decrypted file on disk. They give you a false sense of security. Files, even if they get deleted, remain on hard disks. On SSDs they are even harder to remove, as there is a complicated layer of indirection. Even if you shred the file before deletion, it's possible that it will keep being stored by the SSD, maybe even permanently if a block containing the decrypted content is being decomissioned.

The classical gpg based tools have this very same problem. The classical response is to suggest ramdisk usage, ideally for the entire OS (like a live system basically) to avoid getting artifacts onto the disk like clipboard history, cached thumbnails, or log files. pass for example uses such ramdisks. I disagree that this is a good solution though. Of course it is more thorough, but it requires additional intervention/setup, and not everyone has the needed expertise. Instead, I think the encryption tool itself should take care to only store the decrypted content in non-paged RAM, and give users read/write access through a GUI or a TUI. It should be a ready downloadable solution, similar to the TOR browser bundle. The TOR browser is also trying to not put anything onto the hard disk.

So.. this is using chunked AEAD, without source authentication/signing?

What's the actual use case, and why is it any better than plain stream encryption? If you wish to stream authenticated decrypted contents, it would mean 2 layers of chunking.

Is age designed to encrypt large binary files, which seem to increase the file size by 2KB.

Which crypto primitives does this tool use? x25519+chacha?

Finally! :)

How can we know there's no backdoor in it?

meh.

https://stackoverflow.com/questions/16056135/how-to-use-open...

With that I'm guaranteed AES, a known-good encryption algorithm. I have no idea what these guys are doing without reading through their documentation. Hopefully they didn't roll their own.