6
$\begingroup$

When protecting SSH private keys with password-based encryption, what would be a good minimum password complexity+length standard to make cracking the password too difficult to be worthwhile anytime in the near future if the key got stolen / disclosed somehow.

For the purposes of this question, the private key is a 2048 bit RSA key (I don't think that matters for this question but FYI in case there's some relevance I'm not aware of), and it's being encrypted by AES-256-CBC.

I'm assuming of course the key isn't getting stolen by a computer being hacked to a degree that a keylogger could just be installed but rather for example being stolen by some vulnerability like the recent Firefox pdf.js vulnerability that was being exploited in the wild and looking for SSH keys.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
7
$\begingroup$

Both the AES key size and the RSA key size matter, because it's no use adding security beyond the weakest link. Here the weakest link is 2048-bit RSA, which is considered roughly equivalent in security to 100-128-bit symmetric keys (depending on who you ask). So having a password with much more than 100 bits of entropy would be fairly useless.

In practice, it depends on how much you value your security. 80 bits is enough to be secure against most, but a large adversary like NSA might be able to crack it if they put enough resources to it. 100 bits should be secure against anyone for several decades at least.

For what that means in practice, some examples:

  • 80-bit password: 14 random alphanumeric characters (upper and lowercase).
  • 80-bit passphrase: six diceware words.
  • 100-bit password: 17 random alphanumeric characters.
  • 100-bit passphrase: eight diceware words.

However, there's one important fact missing here: key derivation. The AES-256 key must be derived from the password, and with a good password hashing function this effectively adds "computational entropy" to your password choice. Unfortunately, the default for SSH is still, as far as I can tell, a non-iterated KDF that adds nothing.

If you choose to use the stronger (PBKDF2-based) format (Google should help you), you can add 10-20 bits to the password security, depending on the number of iterations. That means you can skimp a bit on password length or just accept the extra security.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ Yeah, removed comment and voted up. You may however indicate that it is optional to use PBKDF's if the passphrase is sufficiently strong and unique. Or vote this comment up of course :) $\endgroup$
    – Maarten Bodewes ♦
    Aug 24, 2015 at 8:39
  • $\begingroup$ @otus would an attacker need the public key to be able to exploit 2048-bit RSA being the weakest link? Also, do you have a good reference for "100 bits should be secure against anyone for several decades at least" - if not, I'll plan to try to find one myself, but I thought you might already know a good one off the top of your head. Thanks $\endgroup$
    – sa289
    Aug 24, 2015 at 17:00
  • $\begingroup$ @sa289, they'd need either the public key or to eavesdrop a successful authentication attempt. Re: 100 bits, keylength.com which I linked shows various authorities being ok with 80 bits currently and 128 for decades. I think the latter has a large safety margin and even 100 bits is enough for decades. $\endgroup$
    – otus
    Aug 24, 2015 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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