Hacker News Reader

Comment by jchw | Hacker News Reader

The main thing that confuses me with age so far is it feels like there's no way to have private keys that are automatically detected and also encrypted on disk. It seems to have a defacto mechanism for a user-local keys.txt, and sops for example uses this. However, as far as I can tell, keys.txt can't be encrypted. It's probably true that on most developer machines even just read-only filesystem access with the user's permissions would be catastrophic, but I feel a bit uncomfortable with how easy this makes it to extract private keys. Am I missing something? I know there's also a mechanism that can use SSH keys as private keys, but sops doesn't support that yet. (It also doesn't work with SSH agent, but that's still better than nothing I think.)

View on HN

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.

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.

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

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

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

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.

> 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