[HN Gopher] age v1.1.0-rc.1: plugin and YubiKeys support
___________________________________________________________________
age v1.1.0-rc.1: plugin and YubiKeys support
Author : FiloSottile
Score : 87 points
Date : 2022-06-11 16:22 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| andrewstuart2 wrote:
| 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.
| beebmam wrote:
| That's interesting, this behavior is one of many reasons _why_
| I love age. I don 't want a key database for virtually any of
| my use cases
| aborsy wrote:
| 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?
| str4d wrote:
| > 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.)
|
| [0] https://github.com/str4d/age-plugin-yubikey/issues/62
| andrewstuart2 wrote:
| 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.
| qbasic_forever wrote:
| 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.
| andrewstuart2 wrote:
| 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.
| dividedbyzero wrote:
| 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
| _wldu wrote:
| Use the DNS: https://www.go350.com/posts/age-file-
| encryption/#age-pki-iss...
| upofadown wrote:
| 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.
| ayushnix wrote:
| It looks like agent support using plugins is finally possible.
| This should make things pretty interesting for password and other
| kinds of secret management.
| str4d wrote:
| 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).
| cvccvroomvroom wrote:
| Ah cool. I use a Yubikey for macOS logon, BitWarden 2FA, and GPG
| secret keys. All of my passwords and TOTPs are in BitWarden.
| dividedbyzero wrote:
| For macOS login? Is that enterprise-only stuff?
| andrewmcwatters wrote:
| 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.
| traceroute66 wrote:
| > lack of support for AES-256 GCM
|
| Why do you need AES ?
|
| 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).
| _wldu wrote:
| 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.
| sedatk wrote:
| Time to sponsor Age then.
| cordite wrote:
| He Used to work for the go cryptography team, taking a
| break now.
| judge2020 wrote:
| Gotta have that military-grade encryption with 256 bits of
| security.
| tptacek wrote:
| Seems unlikely to be true; an obvious counterexample: WireGuard
| also doesn't support AES, and is wildly popular, including in
| commercial settings.
| chlorion wrote:
| 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!
|
| https://github.com/FiloSottile/age/issues/59
|
| https://neilmadden.blog/2019/12/30/a-few-comments-on-age/
___________________________________________________________________
(page generated 2022-06-11 23:00 UTC)