4 ms·

> People forget that keypairs are not like passwords – if Github gets compromised, nobody can do anything with the public key you gave them. Oh, I'm well aware

by jperras 14y ago

> People forget that keypairs are not like passwords – if Github gets compromised, nobody can do anything with the public key you gave them. Oh, I'm well aware of the difference between a public/private asymmetric encryption scheme and a symmetric one. My concerns are more along the lines of my laptop/desktop being stolen, or my home being robbed and my backup disks/USB keys being taken, or even my computer being seized at the US border. There are ways to mitigate those concerns (e.g. full-disk encryption), but I'm very much a proponent of defence-in-depth whenever possible. I should probably clarify that in the post itself, so that readers aren't misled as to the reasoning behind password-protecting your private keys.

apawloski 14y ago
I don't think I understand you here. Are you not keeping these different keys on the same machine?
- jperras 14y ago
  At the time when I wrote this, I had three separate machines that I used regularly: personal laptop, work laptop, work desktop.
  - aeontech 14y ago
    But three keypairs (one for each machine) is still not "quite a few"... And if you had more than one per machine, can you clarify why?
  - harshreality 14y ago
    The arguments you've presented so far in favor of multiple keypairs on one computer (different keypairs for different remote services) make no sense. Typical ssh usage is one keypair per account per machine (or one keypair per type, e.g. I have an rsa keypair and ecdsa keypaor). It doesn't matter if you use the same keypair for github and ec2 instances [1]. The only way for the key to be compromised is if your local machine is compromised. If the local machine is compromised, you can't trust any keys stored on it unless you know when it was compromised and you know you haven't entered the passphrase for some of the private keys since the compromise. More than likely, you won't know that, so you will have to treat all keys on the compromised machine as compromised. You'll have to regenerate and redistribute N keys instead of 1. In your parent post, you identified physical theft as your main concern. Assuming you have a good passphrase, physical theft is a non-issue. Border crossing seizures and court proceedings are different; in some cases they can demand that you enter your passphrase(s), but multiple keypairs will not help you there. [1] caveat: of course if you use unprompted authentication forwarding, this becomes an issue... a compromise at github for instance could allow the github hacker to ssh into your EC2 instances using forwarded credentials, but that's a time-limited attack and only works while you're connected to github. Private keys never leave the machine(s) they're hosted on.
    - jperras 14y ago
      You make some good points that are making me rethink my key-per-service approach. Though, other than the need to replace N keys when my machine(s) is compromised, there's not that much key management overhead.
w1ntermute 14y ago
> even my computer being seized at the US border If your computer is seized at the US border, the security of your SSH keys is the last thing you need to be worrying about: http://xkcd.com/538/ http://xkcd.com/538/

by jperras 14y ago

apawloski 14y ago

I don't think I understand you here. Are you not keeping these different keys on the same machine?

jperras 14y ago
At the time when I wrote this, I had three separate machines that I used regularly: personal laptop, work laptop, work desktop.
- aeontech 14y ago
  But three keypairs (one for each machine) is still not "quite a few"... And if you had more than one per machine, can you clarify why?
- harshreality 14y ago
  The arguments you've presented so far in favor of multiple keypairs on one computer (different keypairs for different remote services) make no sense. Typical ssh usage is one keypair per account per machine (or one keypair per type, e.g. I have an rsa keypair and ecdsa keypaor). It doesn't matter if you use the same keypair for github and ec2 instances [1]. The only way for the key to be compromised is if your local machine is compromised. If the local machine is compromised, you can't trust any keys stored on it unless you know when it was compromised and you know you haven't entered the passphrase for some of the private keys since the compromise. More than likely, you won't know that, so you will have to treat all keys on the compromised machine as compromised. You'll have to regenerate and redistribute N keys instead of 1. In your parent post, you identified physical theft as your main concern. Assuming you have a good passphrase, physical theft is a non-issue. Border crossing seizures and court proceedings are different; in some cases they can demand that you enter your passphrase(s), but multiple keypairs will not help you there. [1] caveat: of course if you use unprompted authentication forwarding, this becomes an issue... a compromise at github for instance could allow the github hacker to ssh into your EC2 instances using forwarded credentials, but that's a time-limited attack and only works while you're connected to github. Private keys never leave the machine(s) they're hosted on.
  - jperras 14y ago
    You make some good points that are making me rethink my key-per-service approach. Though, other than the need to replace N keys when my machine(s) is compromised, there's not that much key management overhead.

w1ntermute 14y ago

> even my computer being seized at the US border If your computer is seized at the US border, the security of your SSH keys is the last thing you need to be worrying about: http://xkcd.com/538/ http://xkcd.com/538/