According to the answers in this question, SSH still uses a very basic algorithm for encrypting keys with a passphrase, which can be attacked at a rate of billions tries per second using dedicated hardware.

Better password protection schemes have been known for a while. Given how popular SSH is and how critical it is to the security of many organizations, I'm wondering why nobody seems to care about this problem?

  • 1
    The problem with guessing passphrases for encrypted private keys is that 1) You have to have the keyfile. You already have trouble if your keyfile is compromised. 2) Determining that you've guessed the correct passphrase. There's some structure to the keyfile but it contains mostly random data.
    – RoraΖ
    Jan 15 '15 at 12:20
  • 1
    It's not the encryption algorithm that's a problem, it's the key derivation algorithm. Encryption is supposed to be extremely fast.
    – cpast
    Jan 15 '15 at 18:34

This is a difficult question to answer, since there's no technical reason why this is true, so you have to speculate why the developers haven't chosen to address the problem.

There's a couple of possibilities, but mainly it's one of compatibility. SSH is 20 years old now, and has had a stable format for key storage for a long time. If you suddenly changed that and made brute force attacks far more difficult, you'd break compatibility. Everyone hates breaking backwards compatibility, so you'd better have a good reason to do it when you do.

Also, consider that the ssh key format is around 20 years old now. That's 20 years of Moore's law. In 1995 a high end computer was a pentium 133. In 2015 we have multi core processors running at 1.8 ghz.

If you look at code cracking speeds of 1995 vs 2015 for RC5, you'll see 246,000 crypts/sec for a Pentium 133 in 1995, vs 6.1 billion for a modern Athlon multi-core processor. That's 25,000 times faster. So you can see why when the standards were created 20 years ago brute forcing passwords wasn't as much of a concern. Obviously it is now, but backwards compatibility makes the switch not as easy to simply create it.

The other reason is that people consider private keys to be something that attackers don't have access too, and can be kept "safe". If discovered, they can be replaced. That's probably more of a bias towards believing that keys can be kept safe, and discovered if stolen, despite many break-ins being discovered long after they happened.

Ultimately there's no good technical reason why a better key derivation algorithm couldn't be adopted, it's more likely that nobody has made a stink about it in the SSH world. That's normally how long lived standards get changed.

TL;DR Increased brute force speed in the past 20 years has made passwords require more and more entropy. Using better techniques to generate passwords from can mitigate the vastly faster CPUs we now have, but the need for backwards compatibility has delayed moving towards better password deviation techniques.

  • 1
    I'd also suggest that it's probably considered low priority because it's easy to work around. Concerned about the security of the key derivation algorithm? Pick a better passphrase. Jan 17 '15 at 5:30
  • 1
    That's likely true, but it's a bit of self deception. The human mind has a limited ability to remember hard to guess passwords, and as computing ability has gotten larger, we've had to tax our memories more and more. There's no good reason for this. Jan 17 '15 at 6:13
  • 1
    Trying to remember unique passphrases for all of your credentials is already folly — even with a good KDF. It's simply not plausible to expect anyone to remember good (enough) unique passwords with the hundreds of websites and apps they access, not to mention the ones for a laptop, SSH key, GPG key, etc. Password managers are seemingly the only hope for passwords going forward. As an added bonus, it takes fewer keystrokes for me to get my SSH passphrase out of my password manager than it would for me to type it in by hand. Jan 19 '15 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.