Fastest ssh cipher.

cactus · 2005-01-08 08:49:00

I was fiddlying around copying some big files on my local lan.
I was using scp because it is so damn easy. I was getting kinduv piddly speed. Since encryption strength wasn't QUITE as much as an issue because it was on a fairly waffled off section of backend network that I was working on, I was willing to sacrifice some security for a bit more speed.

with scp -c you can pass a cipher directly to ssh.
from the openssh website, the following ciphers are listed:

             Selects the cipher specification for encrypting the session.

             Protocol version 1 allows specification of a single cipher.  The
             suported values are ``3des'', ``blowfish'' and ``des''.  3des
             (triple-des) is an encrypt-decrypt-encrypt triple with three dif-
             ferent keys.  It is believed to be secure.  blowfish is a fast
             block cipher; it appears very secure and is much faster than
             3des.  des is only supported in the ssh client for interoperabil-
             ity with legacy protocol 1 implementations that do not support
             the 3des cipher.  Its use is strongly discouraged due to crypto-
             graphic weaknesses.  The default is ``3des''.

             For protocol version 2 cipher_spec is a comma-separated list of
             ciphers listed in order of preference.  The supported ciphers are
             ``3des-cbc'', ``aes128-cbc'', ``aes192-cbc'', ``aes256-cbc'',
             ``aes128-ctr'', ``aes192-ctr'', ``aes256-ctr'', ``arcfour'',
             ``blowfish-cbc'', and ``cast128-cbc''.  The default is

               ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
                 aes192-cbc,aes256-cbc''

I found a website that had a few speed comparisons of the ciphers, and that spurred me to do a little testing of my own. I tried the following:
scp -C remote@remote:~/bigfile .
2.5MB/s
That gave me crappy performance. The big C does compression. For low speed connections. I was working over a 100mb LAN with a marginal switch.

scp remote@remote:~/bigfile .
9.0MB/s
that was better. Using the default crypto (aes128 with cipher-block-chaining).

scp -c blowfish remote@remote:~/bigfile .
9.5MB/s
an small improvement! blowfish with cipher-block-chaining was a little faster. Blowfish is still a robust algorithm, so I am actually maintaining quite a bit of cryptographic strength here..not too shabby.

scp -c arcfour remote@remote:~/bigfile .
10.8MB/s
wow! Now this is quite a bit better.
Now, arcfour isn't the best thing going. It is a stream cipher, but there have been problems with it. Wikipedia has some good info: http://en.wikipedia.org/wiki/RC4

cactus · 2005-01-08 08:50:58

just found this with a few more ciphers being tested
http://stateless.geek.nz/2004/10/13/scp-performance/

cactus · 2005-01-08 08:55:26

To enable 'blowfish' for a connection your ~/.ssh/config file could read like this:

Host *.archlinux.org
  Ciphers blowfish-cbc

You can also add compression for low bandwidth uses (dial up?)

    
Host *.archlinux.org
  Compression yes
  Ciphers blowfish-cbc

EDIT: Apparently "cipher" is for protocol1, and "ciphers" is for protocol2
http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config

Michel · 2005-01-08 13:08:41

I thought blowfish was optimised for encrypting, ... fast in software.

cactus · 2005-01-08 20:05:17

It is just a block cipher. Originally it was put forth as a potential algorithm for use as the AES standard. Rijndael (gah. I can never spell that right) ended up winning after several years of open discussion.

Don't know about being "optimized for encryption" though. I don't really even know what you mean by that honestly.
:?

Michel · 2005-01-09 13:00:55

What I meant was that it is optimized for doing the calculations (encrypting, decrypting, ... ) fast in software without any extra hardware support ...

oscar · 2005-01-09 19:25:45

cactus, I think it's time for you to start (ab)using nfs.
Seriously.

cactus · 2005-01-09 22:05:19

nfs tunned through stunnel or with ipsec maybe.
*wink*

colnago · 2005-01-10 06:24:48

I am interested about the compression argument. It looks like the speed increased w/o compression. Does that mean your bandwith was limited by the processor speed (extra overhead for compression). Or was the file size smaller so the MB moved was lower but the total transfer time was about the same and thus the MB/s was lower (for compression)?

cactus · 2005-01-10 07:11:10

colnago wrote:

I am interested about the compression argument. It looks like the speed increased w/o compression. Does that mean your bandwith was limited by the processor speed (extra overhead for compression). Or was the file size smaller so the MB moved was lower but the total transfer time was about the same and thus the MB/s was lower (for compression)?

Neither. Moving files between two relatively powerful systems. Once is a Athlon 1800+, the other an Intel 2.8Ghz (with HT). Both have 1GB of ram. I wouldn't think that would be a bottleneck for simple gzip that ssh uses (I think it uses gz for compression).

The test file was a 50MB file made as follows.

dd if=/dev/urandom of=testfile.random bs=50M count=1

I too was wondering why compression seemed to be throttling it so low. I might have to do some more testing. Maybe actually run top on both systems while I transfer to see the cpu usage....

Mythoz · 2005-01-10 09:37:27

Don't know how it affects speed but random data is poison for compression algorithms:

$ dd if=/dev/urandom of=testfile.random bs=50M count=1
-rw-r--r--  1 arch   users 52428800 Jan 10 10:25 testfile.random

$ gzip testfile.random
-rw-r--r--  1 arch   users 52436834 Jan 10 10:25 testfile.random.gz

The filesize even increased because of the gzip header.

cactus · 2005-01-10 21:11:13

Initially I was just using real system data. Lots of text files and large binary files.

Good point about the random data being bad for compression though. Still, why should that slow down the transfer? It should only make it so you are transferring a bit more data.

cactus · 2005-01-13 09:35:37

I doubt it. The overhead of caching the file sizes involved kind of precludes extensive caching.
I certainly don't have over 3GB of ram (at one point I was copying my home dir).
For smaller files this indeed might be an issue. I was initially just fooling around to see if I could get faster transfer speeds based on different ciphers. Lo and behold, arcfour (a stream cipher) got the best overall performance. Blowfish was good too.

arcfour (RC4) does have a few problems, but in speaking with a few crypto guys (professors with extensive knowledge of the field) RC4 can be pretty good as long as you throw away a good portion of the initial pad. Apparently if you toss an initial portion (1k of pad?) then it is actually a pretty good cipher.
I wonder if ssh "does the right thing" in regards to RC4...

Arch Linux

#1 2005-01-08 08:49:00

Fastest ssh cipher.

#2 2005-01-08 08:50:58

Re: Fastest ssh cipher.

#3 2005-01-08 08:55:26

Re: Fastest ssh cipher.

#4 2005-01-08 13:08:41

Re: Fastest ssh cipher.

#5 2005-01-08 20:05:17

Re: Fastest ssh cipher.

#6 2005-01-09 13:00:55

Re: Fastest ssh cipher.

#7 2005-01-09 19:25:45

Re: Fastest ssh cipher.

#8 2005-01-09 22:05:19

Re: Fastest ssh cipher.

#9 2005-01-10 06:24:48

Re: Fastest ssh cipher.

#10 2005-01-10 07:11:10

Re: Fastest ssh cipher.

#11 2005-01-10 09:37:27

Re: Fastest ssh cipher.

#12 2005-01-10 21:11:13

Re: Fastest ssh cipher.

#13 2005-01-13 09:35:37

Re: Fastest ssh cipher.

Board footer