3 ms·

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

andrewstuart2 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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
aborsy 4y ago
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 4y ago
  > 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 https://github.com/str4d/age-plugin-yubikey/issues/62

andrewstuart2 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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

aborsy 4y ago

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 4y ago
> 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 https://github.com/str4d/age-plugin-yubikey/issues/62