neuhalfen.name

A random collection of posts

100% SCP/SSH Performance Gain by Selecting the Right Algorithm

Permalink

I honestly never as much as glanced at the -c parameter of the ssh-suite. But with the advent of GBit that sure has changed!

The article shows the significant performance improvements gained by selecting the right encryption algorithm.

The Test

My testcase is very simple: scp a large file over GBit. This might not be the most sophisticated benchmark but it sufficed for my curiosity.

For the curious: I did not enable compression because the to-be copied file XXXXX is a backup of /dev/zero (backups are important…).

Setup

  • Client: MacBook with Core2 something. OS: MacOS X 10.5.6
  • Server: Athlon 64 X2 4600+. OS: Opensolaris 11/08, running as dom0 under xVM

Local read

The first test shows, that the server has enough reserves for the test. My testfile XXXXX gets dded to /dev/null, first with the default blocksize, then with a large blocksize.

  • Default blocksize
    jens@helios:~$ dd if=XXXXX of=/dev/null
    4276224+0 records in
    4276224+0 records out
    2189426688 bytes (2.2 GB) copied, 46.5982 s, 47.0 MB/s
  • with a blocksize of 8 MiB
    jens@helios:~$ dd if=XXXXX of=/dev/null bs=8M
    261+0 records in
    261+0 records out
    2189426688 bytes (2.2 GB) copied, 13.5355 s, 162 MB/s
  • with a blocksize of 64 MiB
    jens@helios:~$ dd if=XXXXX of=/dev/null bs=64M
    32+1 records in
    32+1 records out
    2189426688 bytes (2.2 GB) copied, 12.1396 s, 180 MB/s

That looks good, especially with large blocks. Besides assuring me that disk is not the bottleneck, reading the whole file a few times up front should limit skew caused by (not) caching.

Lets start benchmarking!

No explicit cipher (aes128-cb)

Merkur:jens jens$ scp jens@helios:/export/home/jens/XXXXX /dev/null
XXXXX 6% 143MB 23.7MB/s 01:22 ETA^CKilled by signal 2.

This is the default behaviour on my machines. Other setups might choose a different default algorithm. According to the OpenSSH homepage the list of availabe candidates is (cited from the man page):

Ciphers
Specifies the ciphers allowed for protocol version 2 in order of
preference. Multiple ciphers must be comma-separated. The default is
“aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc”

Using 3des

I expected 3des to be quite slow, and I wasn’t disappointed:

Merkur:~ jens$ scp -c 3des jens@helios:/export/home/jens/XXXXX /dev/null
XXXXX 3% 82MB 11.7MB/s 02:51 ETA^CKilled by signal 2.

As expected, 3des will not be our performance king today.

Using Blowfish

The next candidate was Blowfish. I expected at least aes performance from it. Let’s see, how it worked out:

Merkur:jens jens$ scp -c blowfish jens@helios:/export/home/jens/XXXXX /dev/null
XXXXX 29% 615MB 36.0MB/s 00:40 ETA^CKilled by signal 2.

Final candidate: RC4

The final candidate is the only stream cipher in the suit: arcfour.

Merkur:~ jens$ scp -c arcfour jens@helios:/export/home/jens/XXXXX /dev/null
XXXXX 9% 202MB 51.7MB/s 00:36 ETA^Killed by signal 2.

Conclusion

Speedwise arcfour wins hands down. I did not expect a more than doubled performance over the default aes128-cbc. Who would have thought that switching the algorithm makes that much of a difference.


2009, March 28 – 09:20
RC4 = insecure

Although RC4 may be fast, AES is the default for a reason: RC4 is not very secure and is considered deprecated. Remember WEP?


RC4 = insecure

Hi. Thank you for your objection.

I use the ssh toolset for two different things: To copy large files over the fast and trusted intranet and as a tool for remote administration over insecure lines.

I do remember WEP (who doesn’t). You are right, when you point out that RC4 is insecure. I wouldn’t use RC4 over the internet (or any other untrusted connection) but for the first use case RC4 is good enough. If I have to copy sensitive data or have to use the internet I normally fall back to Blowfish.

Comments