Age is a simple, modern and secure file encryption tool, format, and Go library

Server deployment/management tools like Ansible have their own file encryption and string encryption tools builtin.

Can you elaborate on how age (and the downstream packages) has made a difference in your workflows?

I’ve used git-crypt[0] with great success. It uses git smudge so you never commit secrets if you set it up properly the first time.

Unfortunately, it doesn’t support groups.

For a solution that scales to teams, check out SOPS[1]. You have to do a little more work to be sure that secrets are ignored in the repo but it works reasonably well and is well known.

Transparent support at the editor level (age.el) sounds really nice though.

[0] https://github.com/AGWA/git-crypt

[1] https://github.com/getsops/sops

I have been using agenix and it is very helpful. I am also looking into writing a system module that makes it easy to generate secrets on the fly.

A lot of secrets are just things like, backend and frontend of some service need to be configured with matching keys, but are both running on the same device. In that case you could have a systemd service which just generates a new random key if it doesn't already exist, and then ensure that the dependent services wait for that service to complete. That way you don't have to store anything in git for those at least.

Maybe I'm dense but I can't figure out howto verify/authenticate encrypted files.

Is there something missing in the documentation.

Age is great. I used the rust crate to write an ftp server that encrypts the files before they hit disk (specific use case is having a drop box for my network scanner) and I love the simplicity and composability it provides.

One feature request: it would be awesome to have paraphrase encryption for age private keys.

Have you considered writing passage in Go to integrate age and age-plugin-yubikey as a single binary to make it more convenient to setup and use?

Hi

Do you have an opinion or comment on this? https://news.ycombinator.com/item?id=41159236

Meh. The author of age is very experienced and known specifically for security, crypto and within the implementation language (Go).

Audits are only as good as the competence of the auditors and can often turn into checklist rituals. It certainly doesn’t hurt, but audits are not a panacea.

This drives me a little nuts. There are something like 4 firms† in the world generally recognized as qualified for assessing cryptosystems, against dozens well-known and qualified to audit software but not cryptography. Cryptography is a rare specialty for software security people. How were you going to know whether an "audit" for age was meaningful?

† and, to be fair, dozens of independent practitioners

The description claims these curves are "safe" but nothing pops up when I Ctrl+F `audit`. https://safecurves.cr.yp.to

Doing one thing and doing it well is all and good, but most people are not interested in having to manually mess around with up to 4 raw keys in the pursuit of that. That's particularly true if you are doing pipes and you don't have any good place to put all those keys.

Most of the time you want to go:

    gpg --sign --encrypt file

Isn't POSIX userspace mostly standardized? We should be pretty conservative with what goes into such a standard, but something like age and jq IMO meet that level of utility to justify it.

just "my script might just use it and expect you to have it"

That is one path to standardizing something - using it.

Could zipping the file with a password work as an encryption?

'Git' is a preexisting word; it'd be pretty strange to pronounce it with a soft G.

https://en.wiktionary.org/wiki/git#Etymology_1

https://en.wiktionary.org/wiki/git#Etymology_2

It'd be like naming your software fukr and then insisting "no no no, the R is pronounced 'are', not 'er'."

Is the "like gif" part a joke? You can't use a famously ambiguous word as an example of pronunciation!

Thanks for sharing, always happy when my projects inspire alternatives addressing different parts of the design space. Here are a few quick comments based on skimming the documentation, let me know if I misinterpreted anything.

- signing support

This has always been a non-goal for age. It makes the UX significantly more complex, but it's good if different tools have different goals.

I can't quite make out from https://www.kryptor.co.uk/specification if it does proper signcryption, sign-then-encrypt (vulnerable to signature stripping and re-signing), or encrypt-then-sign (vulnerable to decrypt-reencrypt-forward, like OpenPGP). If the latter two, it's a missed opportunity to offer more security than age+minisign can offer and I encourage the author to look into it!

- sender authentication

I wrote about this. tl;dr age has authentication, but I am not sure what a non-sharp UX around it would be, so I don't advertise it. https://words.filippo.io/dispatches/age-authentication/

- post-quantum security

As https://www.kryptor.co.uk/security-limitations#post-quantum-... acknowledges, "the asymmetric algorithms in Kryptor aren't post-quantum secure". There is support for adding a pre-shared symmetric key, although I did not find the pre-shared key in the usage section, but I would argue that is not asymmetric encryption.

In this sense, I would actually argue that Kryptor is just as post-quantum secure as age: age's symmetric encryption (the passphrase mode) is post-quantum (see https://words.filippo.io/dispatches/post-quantum-age/). We don't support adding a pre-shared symmetric key to asymmetric encryption, but if you have a secure channel to establish a pre-shared key, you should just use passphrase mode.

age does have a third-party fully post-quantum asymmetric encryption plugin (https://github.com/keisentraut/age-plugin-sntrup761x25519) and I plan to make an ML-KEM one once the standard is out.

- key commitment

This is a pretty wonky topic. age as a whole is key committing (you can't make a file that decrypts with two age identities as different plaintexts, some academic researchers tried!). Our file key encryption is not (https://github.com/FiloSottile/age/commit/2194f6962c8bb3bca8...) which means that if you host an online service that accepts an age file and decrypts it with a passphrase and returns an error if it's incorrect, an attacker can do a bruteforce two passphrases at a time instead of one at a time. Given the online oracle is already unusual as a setting, I am not interested in adding complexity to solve this one.

- private key encryption

age supports that! https://github.com/FiloSottile/age?tab=readme-ov-file#passph...

It's not the default because most threat models don't need it: if you have FDE, who's an attacker that can read files from your disk but not replace the age binary in $PATH?

- indistinguishability from random

Not an age goal, actually we very intentionally put "age-encryption.org/v1" in the header so you can run file(1), and specify the type of the recipients to help plugins disambiguate files. The default recipient type doesn't leak any other metadata (i.e. you can't link age files encrypted to the same recipient).

- size padding

This is a good idea and slated for age v2.

I'd never heard of this. Looks very very interesting!

I'd be keen to know Filippo's (age creator) opinion on this, if he has any.

It does not support hardware keys.

An Age key can be in a PIV slot of a Yubikey. With a secret manager such as Passage, you will have secure access to secrets.

Use specialized backup tools! There are cryptographic constructions designed specifically for backup. You will get better backup and better encryption.

If you make a second backup tomorrow, you'll end up with a new (huge) encrypted tar. restic handles deltas when creating a second backup, and writes new files so that tools like rsync or rclone have to do less work to upload the new data.

That said, I don't see anything strictly _wrong_ with your approach.

I made a tiny shell script that combines tar+age, you may find it useful for simplicity

https://github.com/arcxio/urn/blob/main/urn

It’s obviously not practical except for small data, for many obvious reasons.

You may expect tools such as restic or Borg or rclone should use Age. But they don’t, because they need their own file formats.

Restic is excellent. I can’t recommend it enough.

Even then openssl or sq can solve the problem in the same number of commands but with sntabdards.

Using OpenSSL to properly encrypt a file is next to impossible, and if you actually succeed at doing so, you’re very unlikely to be following a defined standard.

I’m not familiar with sq.

modern implementation of the PGP standard

The PGP standard is an unmitigated disaster.

Age uses standard (and modern) cryptography, and is itself standardized[1].

This is in contrast to the PGP ecosystem, which is infamously fragmented and insistent on maintaining support for insecure and home-baked schemes (e.g. 4880’s weird custom CFB mode). Sequoia has made some progress on the UX side of things, but PGP is a dead horse as far as modern, even conservative cryptographic software design goes.

[1]: https://github.com/C2SP/C2SP/blob/main/age.md

trusts this specless tool will be maintained forever

As per the third sentence of the readme there indeed is a spec[0]. There is also an alternative implementation in the form of rage[1], as well as numerous others listed on the awesome-age page[2].

[0]: https://github.com/C2SP/C2SP/blob/main/age.md

[1]: https://github.com/str4d/rage

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

Age is not specless.

Pretty sure age does have integrity and authenticity due to the use of AEAD.

Or Minisign (https://jedisct1.github.io/minisign)

I always use minisign [1] for this. It is small and self-contained.

[1] https://github.com/jedisct1/minisign

No, it’s here (scroll all the way to the bottom):

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

$this is a much better experience than $that, even though it only has a subset of $that's features

I concur, and:

sed 's/even though/because'

Such an appropriate name.