5 ms·

We did eventually add support for encrypted native key files, despite my skepticism around what threat models it actually addresses. You can now pass to “age -d

We did eventually add support for encrypted native key files, despite my skepticism around what threat models it actually addresses. You can now pass to “age -d -i” a file encrypted with “age -p”. Not having a default keychain location though is a deliberate decision that’s here to stay. age keys are application-specific keys, not universal personal identities. We want to avoid implicit state and make rotation and compartmentalization as easy as possible.

jchw 5y ago
Oh, OK. So if sops wants to support encrypting its own keys.txt file, it would need to be implemented on their end. For some reason, I was under the impression age itself had some logic for keys.txt files. I understand that it is an ugly and imperfect layer of security to secure keys this way, but I still prefer it over nothing. Maybe applications could try implementing OS-level 'secure' keyring storage; that seems marginally better... No idea, though, I'm no expert on security. Thanks for age regardless. I'm sure I'll be using it a lot in the future.
- ricardobeat 5y ago
  Where do you store the key that decrypts your key file?
  - jchw 5y ago
    You can encrypt with a passphrase.
    - ricardobeat 5y ago
      Then why not encrypt the files directly with the passphrase? I think this is where the author mentions “questionable” security improvement from supporting key files.
  - xoa 5y ago
    Hardware? I assume if someone was concerned about key access they wouldn't want keys on their filesystem at all but move them into an HSM instead. Since age identities can come from standard input I assume it'd be feasible to put together a workflow there coming from one of the various cli utilities for interacting with keys. There is already a YubiKey specific age plugin [0] getting worked on as well. Currently in beta but looks interesting. Hopefully that will continue to expand to cover other common options. HSM support is pretty important for a modern encryption utility IMO but unfortunately the landscape is pretty all over the place too, so makes sense to just leave it to plugins or as part of a unix flow. ---- 0: https://github.com/str4d/age-plugin-yubikey https://github.com/str4d/age-plugin-yubikey
- str4d 5y ago
  > For some reason, I was under the impression age itself had some logic for keys.txt files. An early version of the draft spec did include a default keys.txt path, and I implemented it in rage. However, during the beta phase discussions we made the decision Filippo described above, and I removed support for a default path in rage 0.5.0.
tialaramex 5y ago
> age keys are application-specific keys, not universal personal identities. Not a courtesy you extended to SSH keys, choosing to instead re-use them for an unrelated purpose, with, so far as I can see, still no proof in 1.0 that this is actually safe, just the usual hand-waving.

jchw 5y ago

Oh, OK. So if sops wants to support encrypting its own keys.txt file, it would need to be implemented on their end. For some reason, I was under the impression age itself had some logic for keys.txt files. I understand that it is an ugly and imperfect layer of security to secure keys this way, but I still prefer it over nothing. Maybe applications could try implementing OS-level 'secure' keyring storage; that seems marginally better... No idea, though, I'm no expert on security. Thanks for age regardless. I'm sure I'll be using it a lot in the future.

ricardobeat 5y ago
Where do you store the key that decrypts your key file?
- jchw 5y ago
  You can encrypt with a passphrase.
  - ricardobeat 5y ago
    Then why not encrypt the files directly with the passphrase? I think this is where the author mentions “questionable” security improvement from supporting key files.
- xoa 5y ago
  Hardware? I assume if someone was concerned about key access they wouldn't want keys on their filesystem at all but move them into an HSM instead. Since age identities can come from standard input I assume it'd be feasible to put together a workflow there coming from one of the various cli utilities for interacting with keys. There is already a YubiKey specific age plugin [0] getting worked on as well. Currently in beta but looks interesting. Hopefully that will continue to expand to cover other common options. HSM support is pretty important for a modern encryption utility IMO but unfortunately the landscape is pretty all over the place too, so makes sense to just leave it to plugins or as part of a unix flow. ---- 0: https://github.com/str4d/age-plugin-yubikey https://github.com/str4d/age-plugin-yubikey
str4d 5y ago
> For some reason, I was under the impression age itself had some logic for keys.txt files. An early version of the draft spec did include a default keys.txt path, and I implemented it in rage. However, during the beta phase discussions we made the decision Filippo described above, and I removed support for a default path in rage 0.5.0.

tialaramex 5y ago

> age keys are application-specific keys, not universal personal identities. Not a courtesy you extended to SSH keys, choosing to instead re-use them for an unrelated purpose, with, so far as I can see, still no proof in 1.0 that this is actually safe, just the usual hand-waving.