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.
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…).
- 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
The first test shows, that the server has enough reserves for the test. My testfile
/dev/null, first with the default blocksize, then with a large blocksize.
- Default blocksize
jens@helios:~$ dd if=XXXXX of=/dev/null4276224+0 records in4276224+0 records out2189426688 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=8M261+0 records in261+0 records out2189426688 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=64M32+1 records in32+1 records out2189426688 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)
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):
Specifies the ciphers allowed for protocol version 2 in order of
preference. Multiple ciphers must be comma-separated. The default is
3des to be quite slow, and I wasn’t disappointed:
3des will not be our performance king today.
The next candidate was
Blowfish. I expected at least
aes performance from it. Let’s see, how it worked out:
Final candidate: RC4
The final candidate is the only stream cipher in the suit:
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.