Ask HN: How do you manage your private keys?

what is your name, email, date of birth, social security number and credit card number please

Don't copy your keys. Don't manage or "organize" your keys. Don't share your keys.

The leaky abstractions around what you're doing with keys is a security illusion, and you need to stop.

Does anyone have any actual useful/helpful comments?

I segment my private keys into two broad groups -- ones I use for certs and long-term crypto, and ones I use for encrypted communications. The cert/long-terms keys are kept on a flash drive (plus a backup drive kept elsewhere) that is under physical lock and key when not actively needed.

The comms crypto keys are kept on a different flash drive that I'm less rigorous about, as I need to have it handy in order engage in the communications. I mitigate this loss of rigor by replacing them reasonably frequently.

All the flash drives involved are encrypted themselves, as well.

I always generated new keys on new devices. I never moved a private key off the device where it was generated. It just felt like doing so creates all sorts of opportunities for mistakes and loss. While it's more work to add or rotate public keys than it is to move private keys, IMO it's also safer.

When I had to manage keys for a bunch of servers and services, at first I segmented them by scope of potential compromise. For example, I had one key pair for my hosting environment, and a separate one for Github, since I had access to more repos than just the apps I was hosting.

But eventually I stopped doing that because the weak point was the device; if my device was stolen, so were all the private keys, no matter how many there were. So, might as well just have one key per device.

I always set passwords on my private keys, and stored the password in an encrypted file: either KeePass, or Keychain on my Mac.

I managed all my SSH hosts a .ssh/config file, so I could connect on the command line with just a nickname.

Edit: this was all to manage an infrastructure for developing and hosting a few dozen websites.

One key, on a Nitrokey. Use pgp auth for ssh, sign all of commits

There is no good answer if you can’t set up a system that can manage temporary access for your disparate employees. You can escrow the keys you need off a master and set up hardware devices like yubikeys with word-based passwords unless you want to teach people how to use gpg (you don’t). Then you can put them in tamper evident bags and mail them. You can send unlock passwords once receipt has been confirmed.

Order a laptop with enough USB port types for the systems being used by remote employees in addition to an aegis secure thumb drive. Pull the hard drive and wireless card from the laptop and boot from a Linux live CD for all of the escrow. You can make a local git repo on the thumb drive for version control and store the master as well as stubs, pubs, and private keys. Hell, put the key card passwords in a file on there. Wgaf- that aegis device is going to self-encrypt and format itself if you get the password wrong enough times.

This is all fun and good, but it doesn’t scale. What do you do when you have 20,30,40 employees? What happens when you hire Frank, the non-techie? That’s the guy that needs this the most.

I guess a middle ground is to email out instructions for people to generate key pairs with passwords, have them send in their public keys, and start using something like sssd for ldap based auth where you can store their public keys in their user attributes.

Anyway, it’s still a problem we’re all interested in a push-button answer to.

I generally have one per user per server if its a Production machine, this is where ssh/.config really helps to keep things organised. This private key never leaves this device.

If it is my own stuff I tend to just have one across most things for ease of use.

I might start looking into some services to manage them but its just easy to be paranoid about moving them off the devices - opens up opportunities!

Using a different passphrase for each key means you then have the problem of working out where to keep the passphrases. It is a little better in that the passphrase can be stored separately - and realising (compromising?) the asset requires compromise of both the passphrase and the protected key.

The number of entries you describe rather implies that you will need some automation over bringing the key and the passphrase together (e.g. a html5 application connecting to 2 different services with separate authentication).

I try to minimize complexity and ideally use a single key for all clients, projects etc. This works well for SSH and reasonable well for PGP. I store my key on a Nitrokey Pro secure USB key so that I can carry it with me and safely use it in any environment. This way I don't have to use separate keys even from the security perspective.