Recommended password complexity for SSH key encryption using AES-256-CBC

Question

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.

Answer 1

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.