Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
NB: These are largely BJH's thoughts. The current UI for selecting crypto algorithms for SSH is a mess, and neither permits nor encourages the user to make rational choices between algorithms. Amongst other failings: * Algorithms of widely differing strengths are grouped together, so AES-128 and AES-256 are treated precisely the same. * The requested group size for DH GEX is fixed. * The selections for the various types of algorithm are entirely independent. * There's no choice of MAC algorithm at all. To my mind, the important aspect of cipher selection is how much security the user wants, and how much speed they're willing to lose to get it. I'd thus suggest having two basic controls: 1: desired security level, in bits. 2: option of preferring security over speed, or vice versa. In the case where the user prefers security, PuTTY would simply list all of its algorithms in order of decreasing security and warn if one below the threshold was used. Where the user prefers speed, PuTTY would list algorithms that match the security level in order of speed first, and then the rest in order of security, again warning if the requested level was not met. DH GEX parameters can be chosen either based on the user's selections or, more usefully, based on the algorithms actually negotiated. NIST Special Publication 800-57 provides convenient mapping between symmetric and asymmetric strengths. It suggests: 80 bits == 1024-bit RSA/DSA/DH 112 bits == 2048-bit RSA/DSA/DH 128 bits == 3072-bit RSA/DSA/DH 192 bits == 7680-bit RSA/DSA/DH 256 bits == 15360-bit RSA/DSA/DH In SSH-2, hashes are generally only required to be preimage-resistant, so they can be treated as having their full rated strength. Thus, we get the following strengths for the various algorithms: diffie-hellman-group-exchange-sha256 <= 256 (tunable) diffie-hellman-group-exchange-sha1 <= 160 (tunable) rsa2048-sha256 112 (<= 256 for longer keys) diffie-hellman-group14-sha1 112 rsa1024-sha1 80 (<= 160 for longer keys) diffie-hellman-group1-sha1 80 aes256-{cbc,ctr} 256 arcfour256 256 (but warn anyway) aes192-{cbc,ctr} 192 blowfish-{cbc,ctr} 128 aes128-{cbc,ctr} 128 arcfour128 128 (but warn anyway) 3des-{cbc,ctr} 112 des-cbc@ssh.com 56 hmac-sha1{,-96} 160 hmac-md5{,-96} 128 I think a reasonable default would be a minumum strength of 112 bits, since that can be fulfilled with only REQUIRED algorithms. Given PuTTY's historic tendancy towards AES-256, I'd also suggest preferring security over speed. TODO: How does the strength of the host key affect all this? TODO: Do we care about the difference between the strength against on-line attacks (MAC, hostkey) vs off-line attacks (KEX, cipher)? The NIST document provides security lifetimes for various strengths of algorithm, so a really high-level interface would be to ask the user how long they want their data kept secure for, check the current date, and use appropriate algorithms. I'm not sure making cipher selection date-sensitive is really wise, though, and NIST think 112 bits are enough until 2030 anyway. TODO: We probably need some finer options for control freaks (and new attacks).
Audit trail for this wish.