9 ms·

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

126 points by talonx 4y ago

ianpurton 4y ago
There's also a rust version. https://github.com/str4d/rage https://github.com/str4d/rage
eterps 4y ago
The (CLI) user experience looks very clear and straightforward. Especially having these small explicit public keys.
bertman 4y ago
I'm eagerly awaiting the Kotlin implementation of age[0] because once that's finished, Android Password Store[1] will be able to offer age encryption next to/ instead of gpg. 0: https://github.com/android-password-store/kage https://github.com/android-password-store/kage 1: https://github.com/android-password-store/Android-Password-Store/issues/2061 https://github.com/android-password-store/Android-Password-S...
- encryptluks2 4y ago
  Next to is fine, but instead of would be a huge loss. Although GPG gets a lot of unwarranted hate, it is still a very powerful tool that I won't be replacing anytime soon.
- str4d 4y ago
  Ooh, nice! Having a Kotlin-native implementation will be a significant UX improvement over e.g. using my Rust age implementation via FFI / JNI behind a wrapper. It also reminds me (again) of the cross-language plugin question. The CLI apps interact with plugins using an IPC protocol over stdin/stdout. The idea was that the plugin side of the IPC could be placed in front of a regular Recipient or Identity library interface, so plugin authors could offer both a plugin binary for any CLI app, and a plugin library that can be compiled into other apps of the same language. Libraries in other languages sit somewhere in the middle ^_^;; It's probable that e.g. my age-plugin-yubikey Rust code could also be wrapped via JNI and used directly as a library, but there's maybe an IPC-over-FFI approach that could work as well. It would definitely be nice if only the main age client needed to be ported to target languages (though it should be similarly possible for language ports of plugins to work).
upofadown 4y ago
Age is great and all but it has a huge footgun. It encourages the user to encrypt material with a public key in a way that is entirely unauthenticated. So an attacker with access to that public key can simply overwrite the file with whatever they want. If ensuring that you end up with the same stuff as you encrypted is important than that can be a big problem. Fixing this involves the use of a separate signing utility and thus introduces an entirely different set of keys for the user to manually manage. By doing the key management for the user, GPG actually ends up being a lot more usable...
- e3bc54b2 4y ago
  OTOH if you already have another checksumming mechanism in place (oh hello there, git!) age can piggyback off that and ensure there's no switcharoo.
  - lijogdfljk 4y ago
    Mind describing (to a layman?) how checksums can help Age prevent switcharoo? I ask because i've been writing a datastore of sorts that's immutable. Ie all content addressed. I plan to add some basic encryption for cloud storage primarily, however if Age could let someone swap file contents then i can't use Age. I know someone's thinking "if it's content addressed how can someone tamper with the file contents?" - they can't, of course, but that only works if you know the HEAD's to point to. If you don't, say you're doing a full recovery, you slurp in all the content IDs and now have to determine which one is the HEAD. This is where tampering could take place, hypothetically, as they could not just swap the file contents but _also_ change the hashes/content IDs. In a content addressed system signing the HEAD is really the only thing needed, since everything else can be validated via checksum. However i think it still needs signing, no? Sidenote, i know next to nothing about crypto practices. I desperately need to find a class which teaches necessary knowledge to use crypto correctly in your own programs.
    - e3bc54b2 4y ago
      Right, I am just as much of a n00b at crypto as next guy/gal, but here's my understanding. GP mentioned that detecting switcheroo is not possible because both original and new secret will be encrypted by the same public key. Until the decrypted secret is actually used, we will not realise it. But, if we track all the changes in git, and have more than one copy (you have them, right?) then it becomes quite easy to detect this. Goes more if git commit access is gated by SSH key or another secret/auth layer. And this, makes detecting and or rolling back a switcheroo possible.
twp 4y ago
The availability of age as a Go library means that it's easy to embed age into other tools. For example chezmoi supports age encryption for your sensitive dotfiles, and you don't even have to install age on your machine to use it. https://www.chezmoi.io/user-guide/encryption/age/ https://www.chezmoi.io/user-guide/encryption/age/ https://www.chezmoi.io/user-guide/encryption/ https://www.chezmoi.io/user-guide/encryption/
vaylian 4y ago
The thing that age is missing: A description of how to use it properly. I've looked into age several times and it is supposed to be a GnuPG killer for file encryption. But there is afaik no document or talk that describes how to use age in practice. Afaik there is absolutely no information about how to manage your public keys and what the best practices are for rotating and distributing them. Part of me really wants to use age, but when it comes to crypto, you need to know how use it properly.
- landmass 4y ago
  I'm in the same boat. The people who understand Age assume everyone can use man pages. I can work my way through them, but I could really use a few explanatory articles with examples.
napkid 4y ago
I use this with Mozilla SOPS to crypt sensible yaml configuration values stored in a Git repo. Works great, fast, and keys and payloads are short.
chasil 4y ago
OpenSSL has implemented all of this functionality for many, many years. https://www.linuxjournal.com/content/flat-file-encryption-openssl-and-gpg https://www.linuxjournal.com/content/flat-file-encryption-op...
- woodruffw 4y ago
  The selling points of these tools is usability and misuse-resistance, not breadth of functionality. OpenSSL broadly fails on both of those metrics (although certainly not on breadth).
  - chasil 4y ago
    Let me know when you have a version for my platform. $ pipe show system | awk /commands="NR==1" SYS$INPUT: OpenVMS V7.3 on node devhost 26-SEP-2022 10:25:12.60 Uptime 4 21:47:44 $ openssl WARNING: can't open config file: SSLROOT:[000000]openssl.cnf OpenSSL> version OpenSSL 1.0.0r 19 Mar 2015 OpenSSL> quit
    - woodruffw 4y ago
      OpenVMS? That's on you, not me :-) You might have bigger problems with an OpenSSL build from 2015/6, assuming it hasn't been backpatched[1]. [1]: https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
      - chasil 4y ago
        Actually, it's on our production system, and I don't use this for TLS.
nodesocket 4y ago
How do this compare to @cperciva scrypt[1]? I've used scrypt before and love how simple it is. scrypt enc test.txt > test.scrypt Please enter passphrase: Please confirm passphrase: [1] https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html
- woodruffw 4y ago
  scrypt is solely passphrase-based; age has "identities". Identities, in turn, can be the private half of an asymmetric keypair, a passphrase (which then uses scrypt under the hood), or a handful of "extension" types, like SSH keys (for the reference implementation). In other words: if you're using age with passphrases, it's very similar to scrypt's CLI. But you can also use it to encrypt to public recipients, similar to how you'd encrypt using someone's public GPG key.
codegeek 4y ago
The author "filosottile" has built some amazing tools. My favorite is the "mkcert" tool. What a breeze to setup https/ssl on localhost within minutes. I guess I should go through his repo. in detail.
aborsy 4y ago
Is there a backup tool yet for age? Also, I would like to point out a major foot-gun with Age. I was using age in the symmetric mode, glad that I am getting a cleanly written ChaCha20-Poly1305 symmetric cipher. This is supposed to be 256-bits symmetric encryption, and quantum-resistance. But if I recall, it seems that the age key file itself is 128 bits! Thus in the symmetric mode, Age provides only 128 bits of security. This is substandard, and in particular secure only until 2035 or so. Worse, Age creates by default a 10-word password from BIP-39 list. That’s actually 110 bits, in default configuration. Again, a good deal weakening the security. I reverted back to GPG AES-256. AES-GCM appears in 2.3. Correct me if I’m wrong. ————- Update: Here are the links for the security level of 128 bits in Age: https://github.com/FiloSottile/age/discussions/423 https://github.com/FiloSottile/age/discussions/423 https://github.com/C2SP/C2SP/blob/main/age.md https://github.com/C2SP/C2SP/blob/main/age.md
- vaylian 4y ago
  > Is there a backup tool for age? Can you elaborate? You can combine age with tar to create an encrypted archive. > But it seems the key itself is 128 bits! Thus in the symmetric mode, Age provides 128 bits of security. Maybe create a github issue for it?
  - aborsy 4y ago
    Tar and encrypt is 1990s backup. You surely don’t expect that everyday I tar 500 GB and upload to cloud, when one file has changed. I mean something like Restic, but using Age as backend. There is an issue for it in GitHub. That’s how I found this.
    - formerly_proven 4y ago
      You'd want your backups to be signed, which age will never do, so you don't want a backup tool using age as a backend.
      - aborsy 4y ago

126 points by talonx 4y ago

ianpurton 4y ago

There's also a rust version. https://github.com/str4d/rage https://github.com/str4d/rage

eterps 4y ago

The (CLI) user experience looks very clear and straightforward. Especially having these small explicit public keys.

bertman 4y ago

I'm eagerly awaiting the Kotlin implementation of age[0] because once that's finished, Android Password Store[1] will be able to offer age encryption next to/ instead of gpg. 0: https://github.com/android-password-store/kage https://github.com/android-password-store/kage 1: https://github.com/android-password-store/Android-Password-Store/issues/2061 https://github.com/android-password-store/Android-Password-S...

encryptluks2 4y ago
Next to is fine, but instead of would be a huge loss. Although GPG gets a lot of unwarranted hate, it is still a very powerful tool that I won't be replacing anytime soon.
str4d 4y ago
Ooh, nice! Having a Kotlin-native implementation will be a significant UX improvement over e.g. using my Rust age implementation via FFI / JNI behind a wrapper. It also reminds me (again) of the cross-language plugin question. The CLI apps interact with plugins using an IPC protocol over stdin/stdout. The idea was that the plugin side of the IPC could be placed in front of a regular Recipient or Identity library interface, so plugin authors could offer both a plugin binary for any CLI app, and a plugin library that can be compiled into other apps of the same language. Libraries in other languages sit somewhere in the middle ^_^;; It's probable that e.g. my age-plugin-yubikey Rust code could also be wrapped via JNI and used directly as a library, but there's maybe an IPC-over-FFI approach that could work as well. It would definitely be nice if only the main age client needed to be ported to target languages (though it should be similarly possible for language ports of plugins to work).

upofadown 4y ago

Age is great and all but it has a huge footgun. It encourages the user to encrypt material with a public key in a way that is entirely unauthenticated. So an attacker with access to that public key can simply overwrite the file with whatever they want. If ensuring that you end up with the same stuff as you encrypted is important than that can be a big problem. Fixing this involves the use of a separate signing utility and thus introduces an entirely different set of keys for the user to manually manage. By doing the key management for the user, GPG actually ends up being a lot more usable...

e3bc54b2 4y ago
OTOH if you already have another checksumming mechanism in place (oh hello there, git!) age can piggyback off that and ensure there's no switcharoo.
- lijogdfljk 4y ago
  Mind describing (to a layman?) how checksums can help Age prevent switcharoo? I ask because i've been writing a datastore of sorts that's immutable. Ie all content addressed. I plan to add some basic encryption for cloud storage primarily, however if Age could let someone swap file contents then i can't use Age. I know someone's thinking "if it's content addressed how can someone tamper with the file contents?" - they can't, of course, but that only works if you know the HEAD's to point to. If you don't, say you're doing a full recovery, you slurp in all the content IDs and now have to determine which one is the HEAD. This is where tampering could take place, hypothetically, as they could not just swap the file contents but _also_ change the hashes/content IDs. In a content addressed system signing the HEAD is really the only thing needed, since everything else can be validated via checksum. However i think it still needs signing, no? Sidenote, i know next to nothing about crypto practices. I desperately need to find a class which teaches necessary knowledge to use crypto correctly in your own programs.
  - e3bc54b2 4y ago
    Right, I am just as much of a n00b at crypto as next guy/gal, but here's my understanding. GP mentioned that detecting switcheroo is not possible because both original and new secret will be encrypted by the same public key. Until the decrypted secret is actually used, we will not realise it. But, if we track all the changes in git, and have more than one copy (you have them, right?) then it becomes quite easy to detect this. Goes more if git commit access is gated by SSH key or another secret/auth layer. And this, makes detecting and or rolling back a switcheroo possible.

twp 4y ago

The availability of age as a Go library means that it's easy to embed age into other tools. For example chezmoi supports age encryption for your sensitive dotfiles, and you don't even have to install age on your machine to use it. https://www.chezmoi.io/user-guide/encryption/age/ https://www.chezmoi.io/user-guide/encryption/age/ https://www.chezmoi.io/user-guide/encryption/ https://www.chezmoi.io/user-guide/encryption/

vaylian 4y ago

The thing that age is missing: A description of how to use it properly. I've looked into age several times and it is supposed to be a GnuPG killer for file encryption. But there is afaik no document or talk that describes how to use age in practice. Afaik there is absolutely no information about how to manage your public keys and what the best practices are for rotating and distributing them. Part of me really wants to use age, but when it comes to crypto, you need to know how use it properly.

landmass 4y ago
I'm in the same boat. The people who understand Age assume everyone can use man pages. I can work my way through them, but I could really use a few explanatory articles with examples.

napkid 4y ago

I use this with Mozilla SOPS to crypt sensible yaml configuration values stored in a Git repo. Works great, fast, and keys and payloads are short.

chasil 4y ago

OpenSSL has implemented all of this functionality for many, many years. https://www.linuxjournal.com/content/flat-file-encryption-openssl-and-gpg https://www.linuxjournal.com/content/flat-file-encryption-op...

woodruffw 4y ago
The selling points of these tools is usability and misuse-resistance, not breadth of functionality. OpenSSL broadly fails on both of those metrics (although certainly not on breadth).
- chasil 4y ago
  Let me know when you have a version for my platform. $ pipe show system | awk /commands="NR==1" SYS$INPUT: OpenVMS V7.3 on node devhost 26-SEP-2022 10:25:12.60 Uptime 4 21:47:44 $ openssl WARNING: can't open config file: SSLROOT:[000000]openssl.cnf OpenSSL> version OpenSSL 1.0.0r 19 Mar 2015 OpenSSL> quit
  - woodruffw 4y ago
    OpenVMS? That's on you, not me :-) You might have bigger problems with an OpenSSL build from 2015/6, assuming it hasn't been backpatched[1]. [1]: https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
    - chasil 4y ago
      Actually, it's on our production system, and I don't use this for TLS.

nodesocket 4y ago

How do this compare to @cperciva scrypt[1]? I've used scrypt before and love how simple it is. scrypt enc test.txt > test.scrypt Please enter passphrase: Please confirm passphrase: [1] https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html

woodruffw 4y ago
scrypt is solely passphrase-based; age has "identities". Identities, in turn, can be the private half of an asymmetric keypair, a passphrase (which then uses scrypt under the hood), or a handful of "extension" types, like SSH keys (for the reference implementation). In other words: if you're using age with passphrases, it's very similar to scrypt's CLI. But you can also use it to encrypt to public recipients, similar to how you'd encrypt using someone's public GPG key.

codegeek 4y ago

The author "filosottile" has built some amazing tools. My favorite is the "mkcert" tool. What a breeze to setup https/ssl on localhost within minutes. I guess I should go through his repo. in detail.

aborsy 4y ago

Is there a backup tool yet for age? Also, I would like to point out a major foot-gun with Age. I was using age in the symmetric mode, glad that I am getting a cleanly written ChaCha20-Poly1305 symmetric cipher. This is supposed to be 256-bits symmetric encryption, and quantum-resistance. But if I recall, it seems that the age key file itself is 128 bits! Thus in the symmetric mode, Age provides only 128 bits of security. This is substandard, and in particular secure only until 2035 or so. Worse, Age creates by default a 10-word password from BIP-39 list. That’s actually 110 bits, in default configuration. Again, a good deal weakening the security. I reverted back to GPG AES-256. AES-GCM appears in 2.3. Correct me if I’m wrong. ————- Update: Here are the links for the security level of 128 bits in Age: https://github.com/FiloSottile/age/discussions/423 https://github.com/FiloSottile/age/discussions/423 https://github.com/C2SP/C2SP/blob/main/age.md https://github.com/C2SP/C2SP/blob/main/age.md

vaylian 4y ago
> Is there a backup tool for age? Can you elaborate? You can combine age with tar to create an encrypted archive. > But it seems the key itself is 128 bits! Thus in the symmetric mode, Age provides 128 bits of security. Maybe create a github issue for it?
- aborsy 4y ago
  Tar and encrypt is 1990s backup. You surely don’t expect that everyday I tar 500 GB and upload to cloud, when one file has changed. I mean something like Restic, but using Age as backend. There is an issue for it in GitHub. That’s how I found this.
  - formerly_proven 4y ago
    You'd want your backups to be signed, which age will never do, so you don't want a backup tool using age as a backend.
    - aborsy 4y ago