10

SSH offers a large variety of algorithms for Ciphers, MACs and KexAlgorithms configuration options. Sometimes I need quick and light (my own internal network), and sometimes I want all the protections I can get (VPN'ing home from DEFCON).

Is there a taxonomy of what's slowest/fastest, and most/least secure (given known attacks on reduction of complexity, or increasing likelyhood of collisions, etc...) set of algorithms for each of the aforementioned categories?

I've read What are the realistic, and most secure crypto for Symmetric, Asymmetric, Hash, Message Authentication Code ciphers?, but I'd like to see more discussion on different recommendations per application (beefy server to server vs mobile device with short battery life and weak CPU), as well as other side-effects of different modes of operation (CBC vs CTR vs ECB) for let's say interactive use, vs file transfer.

Addition: Just found this summary of effective transfer speeds of different encryption algos/modes.

Community
  • 1
Marcin
  • 2,508
  • 1
  • 15
  • 14

2 Answers2

2

An alternative response to the above is that if you're worried about security then focusing on algorithms is largely irrelevant, because where you'll get 0wned is through an implementation bug in your SSH server, not through anyone attacking the crypto. In particular if you're doing something like VPN'ing home from DEFCON then you need to defend against metasploit, not a DES-cracker. You could use the weakest algorithm that SSH normally supports, single DES, and be perfectly safe, because what's going to get you is an 0day in OpenSSH or, if you're not running the latest version, simply that. So you're really asking the wrong question, pretty much any algorithm will keep you secure, it's the implementation bugs where they'll catch you.

Dave
  • 149
  • 1
1

Your choice of cipher is unlikely to make a difference on the performance of SSH. In most cases, your CPU can encrypt/decrypt faster than your network can keep up. In most situations, network bandwidth seems to be the limiting factor.

Therefore, I suggest that you just leave SSH at its defaults. They're fine. The defaults are reasonably secure, and tweaking with the defaults is not likely to provide noticeably better performance.

If you really want to play around with parameters, you can check out SSH's use of compression. By default, all data will be compressed before sending it over the encrypted channel. You can adjust the compression level with ssh -o 'CompressionLevel 6' (replace 6 with any number from 1-9, 1 is fastest, 9 is slowest). However, personally, I haven't found significant gains from changing the compression level. Also, if you are transferring a file that is already compressed with scp, you can turn off compression with scp -o 'Compression no' .... In some cases (where you have a very fast network and a slow CPU), this might help some, though in my experience I haven't found it makes a big enough difference to be worth worrying about.

Of the ciphers supported on my OpenSSH client, all of the following should provide strong security:

            aes128-ctr,aes192-ctr,aes256-ctr
            aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
            aes256-cbc

You should not use des, as it provides weaker security (3des is fine). I'm not sure about arcfour128, arcfour256, and arcfour, as I haven't kept up with the literature in this area, but they seem riskier to me than the others. Of the message authentication code (MAC) algorithms supported on my OpenSSH client, all of the following should provide strong security:

               hmac-md5,hmac-sha1,umac-64@openssh.com,
               hmac-ripemd160,hmac-sha1-96,hmac-md5-96

Of the HostKeyAlgorithms supported on my OpenSSH client, all supported options (ssh-rsa, ssh-dss) are fine and should provide strong security, as long as you choose a key of sufficient length. I'm not familiar with the KexAlgorithms option.

In short, basically all of the cryptographic options provided should be safe enough, except don't use plain des and it might be best to avoid arcfour-based ciphers.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • The performance is definitely affected. `blowfish-cbc` tends to be about 10mbyte/sec faster than the defaults. This is exactly the observation that made me post this question. This is with compression off, as I was already transferring compressed data. – Marcin Mar 21 '12 at 01:16
  • The downside with Blowfish is that it has a very slow key setup. If it's a newer system with AES crypto support in hardware then you may find that the AES variants are now a lot faster. This information wouldn't have been so relevant when the question was originally asked because AES support was less widespread. – Dave Apr 28 '16 at 16:11
  • Should the claim that RC4 will provide strong security be revised? That wasn't true back in 2012, and is _certainly_ not true now. And `arcfour` is even less secure than `arcfour128` and `arcfour256` because, if I recall correctly, it does not drop the initial and most biased portion of the keystream. – forest Apr 16 '19 at 02:05
  • @forest, good points. I'm not up to date on the latest on RC4, but I would be at least somewhat suspicious of relying on it, so I've edited the answer accordingly. Thanks for raising this. – D.W. Apr 16 '19 at 05:53