Ever wondered how to save some CPU cycles on a very busy or slow x86 system when it comes to SSH/SCP transfers?
Here is how we performed the benchmarks, in order to answer the above question:
- 41 MB test file with random data, which cannot be compressed – GZip makes it only 1% smaller.
- A slow enough system – Bifferboard. Bifferboard CPU power is similar to a Pentium @ 100Mhz.
- The other system is using a dual-core Core2 Duo @ 2.26GHz, so we consider it fast enough, in order not to influence the results.
- SCP file transfer over SSH using OpenSSH as server and client.
As stated at the Ubuntu man page of ssh_config, the OpenSSH client is using the following Ciphers (most preferred go first):
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour
In order to examine their performance, we will transfer the test file twice using each of the ciphers and note the transfer speed and delta. Here are the shell commands that we used:
for cipher in aes128-ctr aes192-ctr aes256-ctr arcfour256 arcfour128 aes128-cbc 3des-cbc blowfish-cbc cast128-cbc aes192-cbc aes256-cbc arcfour ; do
echo "$cipher"
for try in 1 2 ; do
scp -c "$cipher" test-file root@192.168.100.102:
done
done
You can review the raw results in the “ssh-cipher-speed-results.txt” file. The delta difference between the one and same benchmark test is within 16%-20%. Not perfect, but still enough for our tests.
Here is a chart which visualizes the results:
The clear winner is Arcfour, while the slowest are 3DES and AES. Still the question if all OpenSSH ciphers are strong enough to protect your data remains.
It’s worth mentioning that the results may be architecture dependent, so test for your platform accordingly.
Resources:
[...] A not-so-strong SSH encryption cipher is used, in order to improve the performance of the SSH transfer. [...]
I know this post is over a year old, but I stumbled across it trying to find a good cipher preference list, as well as exactly what ciphers are supported (are there more than is found in ssh_config(5)?)
At any rate, with regards to your benchmark, you’re seeing these results, because your CPU is the bottleneck. I don’t know what system you ran your tests on, but on any modern system, the disk becomes the bottleneck, and you’ll get comparable performance out of all ciphers. Same would be said if your network was the bottleneck.
What would make a great post is the amount of network bandwidth that each cipher uses, without compression, and compare these to overall security of each cipher. For example, does “blowfish-cbc” use the least amount of network overhead when transferring the data? The blowfish-cbc algorithm has shown to be comparable in strength to AES, and according to your tests, it’s a faster cipher (although most of the Internet will say that AES is substantially faster than Blowfish in general). So, “blowfish-cbc” might be a good-all-around cipher for OpenSSH.
These sort of details are what intrigues myself.
Yeap, these benchmarks focus on the CPU usage. The bottleneck depends pretty much on the particular machines load. If those were nodes doing some intensive mathematics computations, and you were about to backup them, then the CPU may easily turn out to be a bottleneck again.
Though you are right that it’s the disk system which is usually the slowest one. Sometimes the network too, yes, again depending on your particular use-case.
These tests were done in regards to the following article, where the CPU is the bottleneck:
http://blog.famzah.net/2010/08/08/secure-nas-on-bifferboard-running-debian/