Hacker News Reader

Comment by FiloSottile | Hacker News Reader

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.

View on HN

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.

Where do you store the key that decrypts your key file?

You can encrypt with a passphrase.

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.

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

> 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.

> 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.

Reply on news.ycombinator.com