31–40 of 137 posts
Age is good at what it does, but note that afaik you probably should almost always pair it with something like signify[1], because age doesn't have integrity/authenticity verification (by design). [1] https://man.openbsd.org/signify.1
Age is good at what it does, but note that afaik you probably should almost always pair it with something like signify[1], because age doesn't have integrity/authenticity verification (by design). [1] https://man.openbsd.org/signify.1
Earlier quoted context omitted.
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 real…
These? [0] https://github.com/AGWA/git-crypt [1] https://github.com/getsops/sops
https://www.kryptor.co.uk/ is much more secure than age. From their FAQ [0]: >Kryptor uses strong, fast, and modern cryptographic algorithms, offering post-quantum security. It also addresses security limitations of tools like age and Minisign. >Unlike most tools, Kryptor limits metadata by using an indistinguishable from random encrypted file format. Encrypted files have no identifiable headers and are randomly padd…
- 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.
_o/ hi all, age author here! age is the one of my projects that grew most organically into an ecosystem. It's always great to see what people build with it. Happy to answer any questions. Here are some previous discussions 132 points on Feb 26, 2023 | 77 comments | https://news.ycombinator.com/item?id=34936504 126 points on Sept 26, 2022 | 54 comments | https://news.ycombinator.com/item?id=32980141 113 points on June…
Maybe I'm dense but I can't figure out howto verify/authenticate encrypted files. Is there something missing in the documentation.
Specialized tools are simpler than one do-it-all tool.
> The author pronounces it [aɡe̞] with a hard g, like GIF Lol, or 'git' according to one of my more sensitive colleagues.
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'."
Earlier quoted context omitted.
Server deployment/management tools like Ansible have their own file encryption and string encryption tools builtin.
But then you'd have to use YAML
Age (and its rust implementation Rage) combined with agenix[0] and age.el[1] has made my self-hosted deployment and management so, so easy without compromising security. That, when combined with general NixOS conveniences is why I'm able to self-host at all. If not for these, just the anxiety of having to setup new server in case of whatever loss and the associated time/opportunity loss kept me from dong the same for…
Can you elaborate on how age (and the downstream packages) has made a difference in your workflows?