I've always used this site as reference: https://pubs.opengroup.org/onlinepubs/9699919799/

I would love if I could count on Just, fish, ripgrep, or any other multitude of tools that improve upon these CLI apis that were invented ad hoc and ossified in the 70s. Paved a lot of cow paths.

One of the reasons age is so constrained is that the problems best served by direct simple file encryption are quite narrow.

In any case I can think of, people encrypt things because they want to restrict who can know what those things are.

>Why are you signing?

In the context of encrypted files, you would sign because you want to know if an attacker has modified or more simply just replaced your file. Authenticated encryption is considered more or less standard these days.

>Those are different operations.

Except for niche applications like password storage, most people want/need authentication. Giving someone a raw encryption utility like Age is almost always going to result in a situation where that user is not protected against modification/replacement when they do asymmetrical encryption. That is assuming that they can figure out the keys for even just the encryption.

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

Specialized tools are simpler than one do-it-all tool.

> If you encrypt and then sign, an attacker can strip your signature, replace it with their own, and make it look like they encrypted the file even if they don't actually know the contents.

> If you sign and then encrypt, the recipient can decrypt the file, keep your signature, and encrypt it to a different recipient, making it look like you intended to send the file to them.

I might as well encrypt a message "add $10000 to my account" with the bank's public key, sign it with my own key and send it...

Integrating age plugins into this binary is not something I would do, though. Besides the fact that the plugins are separate projects with their own release schedules, they are also in different languages (plugin-yubikey is Rust, plugin-se is Swift, ...), and you would need to fork them anyway for communication. I guess you could bundle the binaries together in a package, and make sure the search path searches for the bundled binaries as a fallback.

Anyway, just want to say that Age is great!

P.S. The author also did an analysis of Restic the backup tool [2] which also prompted me to setup nice backup solution for my machines. Pretty cool.

[0]: https://github.com/ryantm/agenix

[1]: https://github.com/anticomputer/age.el

[2]: https://words.filippo.io/restic-cryptography/

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 only need to care about my SSH key(s). Which I had to anyway. But now the secrets for all the services (except SSH) lie right besides their config. Any change in one or other is directly visible in git log.

In short, age cut down on the number and types of secrets that I have to manage out of band. Which is very good. It's always easier to be able to remember 2 things (config + SSH keys) than 2+n things (config + SSH keys + whatever secret mechanism any service uses, times number of services).

- Manage it out of band. That negates all of the benefits of NixOS, at least for those files. (I.e. you would need additional deployment steps, rollback wouldn't work, you would have to stop and migrate system services that depend on those secrets yourself, etc.)

- Encrypt it and only decrypt it on activation (which happens when switching to a new config or on boot). agenix and nix-sops (the premier SOPS/NixOS integration) are two libraries that you can include in your config to do that. With this, the world-readable store only contains encrypted secrets.

Of course with #2 you still have to manage your private keys (age or whatever SOPS uses) out-of-band but that is significantly less work since those aren't expected to change nearly as much. You can also generally decouple that from your day-to-day deployment workflow.

In terms of NixOS integration, both are on equal footing.

I'm just unfond of yaml is all.

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.

Is using age like this to encrypt my files before uploading them to untrusted cloud storage not ok?

tar > age > cloud

Some comments mention signing with minisign. Should I be doing that like this:

tar > age > minisign > cloud

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

"Better encryption": Can you explain why age's encryption isn't sufficient if it's recommended for encrypting files? Really want to understand how it's recommended for encrypting and sharing a file over an untrusted channel like email, but not recommended to encrypt a file and upload it to an untrusted server.

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.

The option and argument handling is intuitive; it makes sense instantly. It gives a more grounded understanding of what's happening with the encryption process, especially because of the short-form recipient format.

Also, setting it up with a Yubikey and Passage (a GNU pass alternative for Age) was a breeze.

Lol, or 'git' according to one of my more sensitive colleagues.

Having the rust port be "rage" only compounds the problem.

The author's rather Italian-looking name tends to suggest that he wouldn't view a hard G as a possibility for the word "age" either (and the pronunciation link specifically goes to a synthetic Italian pronunciation of the word "aghe"...), so something else is going on.

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

Most people are best off going with a modern implementation of the PGP standard, ideally via a smart card to protect you from key exfil via malware.

Tools like Keyfork, Sequoia, and/or openpgp-card-tool are almost certainly what you want for most personal signing, encryption, and authentication use cases.

You get broad compatibility with many many different tools.

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

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.

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.

- 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’m not really sold on the UR part of PURBs, though: age wants to avoid asking for a passphrase if the file is not passphrase encrypted, and age-plugin-yubikey wants to avoid asking for a PIN if it’s for the wrong YubiKey. These are tradeoffs and it’s not obvious the very end of the spectrum (uniform random) is the right spot.

† and, to be fair, dozens of independent practitioners

I just wanted to say it would be nice to know what makes this implementation secure other than the creator's own words about their own project.

(EDIT: Though I guess you coming out to defend it is good enough signal to vouch in favor of it.)

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.

I'm only bringing up audits because such claim was made, but maybe I should have said "independent verification" instead since it's more general.

Have you seen Filippo's credentials? He's overwhelmingly qualified for this. https://github.com/FiloSottile

> Today, I maintain the cryptography packages that ship as part of the Go standard library (crypto/… and golang.org/x/crypto/…), including the TLS, SSH, and low-level implementations, such as elliptic curves, RSA, and ciphers. These packages are critical to virtually every Go application, securing HTTPS requests, implementing authentication, and providing encryption.

You can think of the cryptography community as similar to the math community. If some nobody makes a new proof of a big conjecture, it is considered with skepticism until some big name comes around to verify it. If Terence Tao comes out with a new proof in one of his specialities, people are going to assume it's basically correct or will have only very minor errors that are easily fixed.

"independent verification" is subjective. Who does the verification, do you trust them, how do you know they didn't screw up.

"benchmarks" are objective. A is faster than B, we know because of the way that it is.

That aside, of course DJB would choose criteria that let him label his own curve as "safe".

I'm no cryptographer so ultimately I have no choice but to rely on others' expertise, but that does not mean I take at face value the words of someone talking about their own project. Probably for the same reason HN requires disclosure when talking about something you're involved in.