The main thing that I wish age had is a key database for managing contacts. It's awesome that it's modern and secure, but having to manage and refer to my key files (and friends' key files) manually is painful. Not that it matters much; for both tools I have a contact list of effective length zero. At least for PGP, I can sign my commits (and various other artifacts) and use my GNU pass/gopass database.
GPG key management is very useful, at least for personal use. For instance, it’s unwieldy to copy paste various keys manually in terminal. The latest versions of GPG offer authenticated encryption as well.
But perhaps age is better suited as a backend in other apps, especially Go apps. A good feature of PIV applet of Yubikey 5 is that it stores 24 keys. compared to 3 in OpenPGP (although any app including GPG could make use of those 24 slots).
What I am looking for these days is a back up tool that uses age. Can an app like restic use age as backend?
> A good feature of PIV applet of Yubikey 5 is that it stores 24 keys.
Note that not all 24 of those keys are suitable for age usage. The 4 main keys have specific usage definitions in the PIV specification that mean hardware tokens alter how those key slots behave. Only one of them (the KeyManagement slot) has a definition that allows encryption, and even that I was somewhat suspicious of overlapping with, as I couldn't predict how those existing keys were being used, and didn't want to support every possible key type that might be in that slot (which users likely wouldn't be able to alter).
age-plugin-yubikey avoids this complexity by only interacting with the 20 "retired" slots, which have no constraining definitions. (I am considering adding restricted support for the KeyManagement slot specifically for CAC card users who aren't allowed to add new keys to their cards [0], but this would be behind a default-off feature flag to keep the primary UX simple.)
What I like is that I can generally run `gpg --encrypt --recipient andrew` and it will search keys by a few different "fields" to find matches. I don't need to remember where I put the key file or even always the person's email vs name. Some people I can remember handles more easily than real IDs and that works just fine with the gpg database implementation.
Why not just put your friend's keys in a well known place by their name, like in your home directory? Then you can just refer to them as ~/identities/andrew for example. You could even add a symlink for andrew's email in the same dir.
This also lets you use your shell's tab completion or even a fuzzy finder to list and select identities.
You're definitely right. I can do that. I can also symlink the files to multiple aliases if I want to be able to use multiple possible references for the same key. But I do prefer it when the tool handles that for me.
I'd like age to remain as simple as it is right now, I'm using it because unlike GPG I can actually use it without having to manpage/google things, but that sounds like a great idea for a more capable utility that wraps age for the GPG use cases that aren't covered well yet
An age key database would be a fundamentally different thing than a PGP keyring. Age doesn't do signatures and as a result can't do authentication for asymmetrical encryption. So an age key database would be just a list of unauthenticated encryption keys. Without the ability to do signatures, that is all it ever could be. So it probably doesn't make sense to bake something like that into the utility.
A PGP keyring is a list of identities. Once you have verified an identity you can not be tricked into using the wrong encryption key for that entity. You can then be sure of the authenticity of any messages/files you get from that entity.
I mean, that's kind of like saying it's fine to have your phone numbers in a text document on your phone, so why bother adding a contacts application, especially since caller ID isn't authenticated.
I get that it's out of scope and wouldn't be that hard at all to implement a wrapper that handles this, but without that functionality I find it much less enticing because I'm left to think about something that the other tool I use handles (and as you've noted, a lot more seriously too).
Age is interesting. After doing extensive reading on the state of the art for file encryption, and collecting dozens of reference articles for further reading for my coworkers to do, I wrote envelope encryption along with a proprietary file encryption standard for a company I previously worked for.
It had only the basic features you’d want for cryptographic agility.
During my reading, I came across age and wanted our business to use it, but it was too early to make that call across the entire business. It had only been released the previous year.
It also missed one crucial feature, which I think is the biggest miss with age: lack of support for AES-256 GCM.
I understand the arguments for not including it.
I also understand that if you want absolutely no serious adoption, it’s fine not to include it.
Age uses ChaCha20-Poly1305 which is more than good enough, and has the added benefit of being an algorithm that is optimised for software only implementation and doesn't need hardware support (e.g. AES-NI instruction set).
Maybe he works for a company that does US government research? Maybe they require NIST approved algorithms. I'm pretty sure that would prevent the use of Age for file encryption.
I really like the general ideas behind age, like being composable in shell commands and having a more narrow focus than something like GPG.
My biggest frustration with GPG is that it needs to have keys imported to do anything useful. I greatly prefer just storing the keys in the file system!
Related to that last point, Gentoo uses GPG to verify distfiles sometimes and it ends up creating a lot of "dummy" keyrings and throwing them away to circumvent this limitation of GPG! (I haven't dug too deeply into the code so it's possible that I am wrong here, but this is my current understanding)
My two primary issues with age that have prevented me from using it are that it doesn't use authenticated encryption (see links below) and that there is no way to encrypt/decrypt and make signatures with a single key pair (at least afaik). If I am encrypting files I want to be able to trust the contents of it fully, otherwise it's really not that useful for me personally!
Obviously, age does use authenticated encryption. What Madden is pointing out is that age doesn't support signing or origin authentication --- not because you'd never need it, but because it's out of scope for what age does. Madden objects to the notion that you'd use minisign to sign an age ciphertext, but it's not clear why we should care about that objection: he's just saying that age loses an efficiency claim when ciphertexts have to be preprocessed to be verified.
Meanwhile, there is no worse format in the world when it comes to authentication than PGP, with the (ongoing!) saga of it's weird, unsound MDC.
>For public key cryptography, the notion of authenticated encryption becomes more complicated. I wrote a three-part blog post about it. There are public key authenticated encryption modes, such as NaCl’s box, but age doesn’t use one of those and instead opts for unauthenticated ECIES encryption (like JOSE’s ECDH-ES algorithm) using X25519. So while age uses symmetric authenticated encryption for the file contents, the symmetric file key is itself encrypted using an unauthenticated mode.
>it is completely insecure to pipe the output of age into another tool without independently establishing the authenticity of the file.
I disagree that it's outside of age's scope. One of the example use cases in the readme is piping age to another program such as tar.
This makes age (without minisign or whatever) useless and/or insecure for most people.
>you can’t simply use a static key pair with age to achieve authenticated encryption as age’s key-wrapping algorithm is completely insecure when used in this way
>an attacker cannot tamper with the encrypted ciphertext, but they can completely replace it with one of their own choosing
>it is completely insecure to pipe the output of age into another tool without independently establishing the authenticity of the file
Can you go into depth about why it's "grossly inaccurate"? So far you haven't actually explained why it's not correct, and these quotes seem to directly support everything that I have said.
Is there an issue with the authors analysis perhaps? Has age since then resolved any of this? I am curious what makes you disagree here.
I suspect that what you are arguing is mostly semantics about age using authenticated encryption during the symmetric phase of the whole process, but since the symmetric key is not authenticated that defeats the purpose as far as I can tell.
It looks like agent support using plugins is finally possible. This should make things pretty interesting for password and other kinds of secret management.
Yep! Plugins themselves are ephemeral - all of their runtime state is provided by the age client - but when the plugin binary is invoked by the age client, it can then connect to (or start) the long-lived agent process and act as a proxy to it.
For YubiKey support specifically, my age-plugin-yubikey plugin handles encryption and ephemeral decryption (meaning that it connects to the YubiKey live, and thus has to treat e.g. "Once" PIN policies as "Always"). Once something like yubikey-agent has been extended to provide an age plugin, you could then take an age-plugin-yubikey identity and convert it into an agent plugin identity (so that the age client knows to invoke the agent's plugin for decryption rather than age-plugin-yubikey).
For the cheaper U2F security keys (or older Yubikeys which do challenge-response stuff).. I've seen comments that had success using U2F for sudo/su, but not the login screen.
