Been using sops-nix with age to encrypt secrets in my configuration. The encrypted secrets are stored in my public git repository.
So far, I’ve only encrypted “less important” secrets (e.g., some wifi certificate), but it would be great if I could use sops-nix + age to also encrypt & commit secrets that are very important, including private ssh keys.
Question: Is the encryption safe enough to commit sops-nix + age encrypted private ssh keys to a public repo?
I’ve read up on some of the basics of age encryption (and the unimaginable time it would take a brute-force attack to break it), but am curious about what other users are doing / where you would draw the line.
One factor to consider is how long the ssh key will be valid for, if its for a week at a time, it’s an obvious non issue, if it’s for 10 years, I’d be weary of it.
The second threat of mishandling secrets remains very real as well, even if you use age (since it doesn’t support key-storing hardware yet, perhaps even more so in that case).
I think “publish on a public GitHub repo” is probably not “reasonably private”. While this wouldn’t result in your secrets immediately leaking, someone may in the future break the encryption used for it. Don’t panic if you’ve shared them already, but maybe consider pulling them offline and changing the secrets and keys involved.
IIRC @Mic92 mentioned at nixcon that it would in theory be possible to add yubikey/piv support to sops-nix and that he would implement it if anyone sponsors a yubikey but I might be miss rembering
sops-nix “supports” yubikeys on the development end because you can use gpg keys. It’s age that doesn’t support them, or rather there is no standard for age yet that could be supported by hardware keys.
It doesn’t support using them at boot time, but that’s less useful/critical since the hard drive your machine-specific keys are on should realistically be encrypted at rest anyway, and for that you can use a yubikey.
Also implied in this, for at least this specific example of your ssh private key
that the file does not have a passphrase encrypting it internally
that it’s not stored and used on the yubikey
Both or either are good ways of addressing the concern in ways that also apply in normal runtime operation as well as in your nix configs.
For the more general question, of course, the issue still applies, but it need not apply for this example that is often rather more directly linked to identity as a crucial long-term secret.
There is also the option (or at least prospect of soon, conveniently) using TPM2 keys as part of the secret protection mix, targetting specific hardware instances, perhaps at minimum using that to protect the key used by age/sops to decrypt the rest.
Finally, beware of publishing git history that may include historical copies of the secrets before you added protections you decided were sufficient.
That would just be double encryption though, right? I don’t think that really addresses the threat that someone may break the encryption if you publish it on github - if someone managed to get past an age key, they can probably crack your passphrase.
Yes, possibly; I’m certainly not going to say it’s impossible.
The emphasis, however, is that the most likely threat is the other kinds of mishandling you raised above, and the measures available help both. That includes passphrases or hardware storage as well as operational measures like expiry or quick revocation / removal of access.
Personally, I don’t put these private keys in the repo (public or otherwise). Partly because they’re used to protect the other secrets that are in the repo. Software ssh keys are per-machine, with passphrases, and vanish together with the machine if that happens (they are backed up, for simple disk failures). Keys on hardware tokens can be used for access in case these are all lost, including initial setup of replacement machines if needed.