Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
You want to avoid CBC in SSH: – indiv Jul 9 '14 at 22:04

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.

share|improve this answer

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.

Edit 3/20: @Marcin mentions that Blowfish got better performance in his tests. Of the ciphers supported on my OpenSSH client, all of the following should provide strong security:


Most likely arcfour128, arcfour256, and arcfour will provide strong security as well, though they are not quite as conservative a choice as the others. You should not use des, as it provides weaker security (3des is fine). Of the message authentication code (MAC) algorithms supported on my OpenSSH client, all of the following should provide strong security:


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 if you are conservative, you might avoid arcfour-based ciphers, though this probably just paranoia).

share|improve this answer
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 1: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 at 16:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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