&
SEO LEO
Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
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).