age.el: age encryption support for Emacs

[https://github.com/anticomputer/age.el](https://github.com/anticomputer/age.el) Since I'm starting to purge gpg out of my life, but do depend on it heavily for keeping my org notes and authinfo encrypted, I needed an epa/epg-style transparent encryption support for age ([https://github.com/FiloSottile/age](https://github.com/FiloSottile/age)). As such I ported the relevant epa/epg code and reworked it to work with age. age.el provides transparent encryption and decryption support for .age files in Emacs, much like epa/epg support .gpg files. That means you can do all the things with .age files you're used to doing with .gpg files in Emacs now. Like most of my packages, this is mostly written to support my personal use cases, but I've seen some other folks mention that they wanted to start using age over gpg, so have a look if this seems useful to you. EDIT: latest version in main also supports [rage](https://github.com/str4d/rage) now, which gets you pinentry support and all that EDIT: if you use the gpg based pass support for Emacs, there is also [https://github.com/anticomputer/passage.el](https://github.com/anticomputer/passage.el) now

Out of curiosity, why did you start "purging gpg out of your life"?

I wanted to reduce the amount of key management in my life to the bare minimum. I don't use gpg for its intended purpose (maintaining a web of trust with folks that you communicate with), but rather only use it for Emacs file encryption and things like password-store (which I'm replacing with [https://github.com/FiloSottile/passage](https://github.com/FiloSottile/passage) and will also port the Emacs pass frontend to work with). Age functions with ssh keys as well as its own key formats, so it hugely simplifies the amount of key material I have to maintain. Especially when managing key material on e.g. YubiKeys, maintaining Encryption, Authentication, and Signing subkeys and juggling what is essentially a personal PKI (not to mention bringing it along on every system) surrounding gpg's key trust relationship maintainance. I use e2e encrypted email and messaging services for encrypted communications and ssh keys to sign git commits. So with age I can also just use my ssh public key to encrypt and my ssh private key to decrypt my files. If I want to get fancy, I can use something like [https://github.com/str4d/age-plugin-yubikey](https://github.com/str4d/age-plugin-yubikey) to provide the key material for my age operations (which should compose with age.el quite well also, i.e. you can have every decrypt operation have a touch requirement in Emacs that way). TL;DR: gpg is overly complex for my use case and I'm currently shoehorning gpg into a role it was never designed or intended to play. Complexity of use and secure use of cryptography don't compose well for most folks, so now that gpg no longer serves any real purpose in my environment, it's time to retire it from my dependency stack.

I'm not qualified to say if these are compelling accounts or not, but various experts have been pointing out user experience issues surrounding gpg for a while now: https://www.openbsd.org/papers/bsdcan-signify.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html# One thing I do like a lot about age is that it can encrypt against an ed25519 openssh key - which is tiny, & the pubkey easy to share.

Did you know you can convert gpg keys to ssh and the reverse? Same with using it for x509. The private/public keys are equivalent in all three, the other formats just add different metadata.

Is it possible to use an ssh key with a non-blank passphrase? From what I understand `age` doesn't support ssh-agent or pinentry and age.el doesn't seem to be able to prompt for the passphrase either. I am able to save files but I get this when trying to open an age encrypted file: age-file--find-file-not-found-function: Opening input file: Age failed with error, failed to obtain passphrase: could not read passphrase for "/home/SOMEUSER/.ssh/id_rsa": standard input is not a terminal, and /dev/tty is not available: open /dev/tty: no such device or address Edit: I see https://github.com/anticomputer/age.el/issues/1 now

I just added rage ([https://github.com/str4d/rage](https://github.com/str4d/rage)) support, which does support pinentry, see [https://github.com/anticomputer/age.el#known-issues](https://github.com/anticomputer/age.el#known-issues) for an example of how to use rage instead. It requires that you have a pinentry program available on your system (gpg's pinentry e.g.)

sure, but that does not really aid in my goal of complexity reduction :)

Why are you using SSH keys for encryption and signing and not openpgp keys for SSH? Using gpg keys on yubikey for everything should be easier than using ssh keys for everything. >I'm currently shoehorning gpg into a role Well, it sounds like you're shoehorning ssh keys into two roles it was never designed or intended to play (encryption and signing), whereas authentication is designed into the openpgp spec. Key trust is entirely optional. If you aren't verifying other people's signatures you don't have to touch it at all.

I think I already answered that question? Complexity (i.e. attack surface) reduction is the primary motivator, reduction in the amount of key material I manage a second, and I'm sure a fair bit of yak shaving because it's a holiday week a third ;) I mean I've used an OpenPGP implementation for 20+ years (including managing a S, C, A subkeys on a yubikey and all) so I reckon I gave it a fair shake, but ultimately (pun intended) it just boils down to personal preference and having better (simpler) tools for the job. GPG is empirically less than stellar in terms of footguns and the many ways you you can misuse it out of the box. There's a reason why the README for e.g. [https://github.com/drduh/YubiKey-Guide](https://github.com/drduh/YubiKey-Guide) is about 10 times as long as the Age based equivalent. Complexity. This makes adoption (and re-adoption) exceedingly difficult for the average person. I'm sure there's many folks that just want to do a few tasks, do them well, and do them with the same key. SSH key material is omnipresent and simple to maintain and move around, especially given something like ed25519. To be fair I don't know what you mean when you say an SSH key was not "designed" for signing. It's just a chunk of key material in a given format not much unlike, as you pointed out, GPG keys. Its suitability as a signature mechanism is mostly based on support in its downstream ecosystem. The only thing I sign are git commits, I can sign those with an ssh key now ... ergo :) But, while it's fun to debate this stuff, again really it just comes down to personal preference and reconsidering old habits I reckon.

> Complexity (i.e. attack surface) reduction is the primary motivator, UX complexity is not the same as attack surface. A program with bad UX that uses a single battle-tested crypto library has a smaller attack surface than a program with a great, simple UX that uses a dozen immature crypto libraries. > reduction in the amount of key material I manage a second You aren't reducing anything though. You traded one openpgp key for one ssh key. Minus zero key reduction. > a fair bit of yak shaving because it's a holiday week a third ;) Well it's your time, spend however you like, even if it seems mysterious to others.

I'm not talking about UX reduction. I'm talking about code surface reduction. As a side note, I've spent my entire professional life as a vulnerability researcher and product security engineer, quite literally auditing code for a living. So thank you for the refresher on attack surface ;) I think it's ironic that you imply a "dozen immature crypto libraries" are used in the Age spec. It's quite the opposite and the Age spec provides a reduction in so-called "yolo crypto" versus the OpenPGP spec. See: [https://github.com/C2SP/C2SP/blob/main/age.md](https://github.com/C2SP/C2SP/blob/main/age.md) and also give [https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#) for a pretty accurate overview of what's wrong with OpenPGP. As far as practical key reduction ... let's do the math here. 1 pgp key + 1 ssh key == 2 keys. Minus 1 pgp key ... carry the 2 ... hrmm ... I end up with 1 key. 1 is less than 2. QED :P EDIT: all jokes aside, this feels like it's turning into one of those "I don't like this and I will argue to the death because of it" type situations which I'm not that interested in participating in. You're certainly entitled to your opinion, even if it seems mysterious to others :)

I'm not opposed to age and rage existing (in fact I think it's a good thing and signify in OpenBSD is nice) and I don't disagree with issues with UX, as I find myself scratching my head and searching the internet for how I need to use gpg for something. My concern with a tool like gpg is more about security than how easy it is to use.

Sure, but ease of use implies lower risk of user error, (not to mention wider adoption) which is relevant from a security standpoint.