blog | edwards research

I use PuTTY (actually, I use PuTTY tray) and XWin Server to run Linux GUI applications in Windows.  Basically, I have a headless Linux server running and I connect to it via SSH.  While 90% of the things I do on it are command-line based, I’ve yet to find a real good strategy for developing true linux C/C++ applications from a Windows machine, so I end up running Eclipse on the headless box with the windows tunneled to my Windows system.  (I say true because I know I could use something like MinGW or Cygwin and get 99% of the functionality, but I’m picky about that last 1%).  Also, I know there is a really interesting project underway in the Eclipse community to get CDT to build and debug remotely (Remote Development Tools), but I ran into all kinds of problems getting it to work and it really wasn’t worth the time I was spending on it.  Further, X tunneling over SSH worked great.

I wasn’t satisfied though.

My LAN’s throughput chokepoint was my router, limiting connections to 100Mbps so I went ahead and ordered a Gigabit switch and upgraded my cabling (it was pretty shoddy) and one of my NICs.  Before they come in though, I decided to explore some ways to improve tunneling without hardware changes.

The first thing I looked into was changing SSH cipers.

You can look at the available ciphers in PuTTY by going into the configuration window, and under Connection, clicking SSH.  You should see something like this:

You can change the the order that these ciphers are considered simply by clicking Up or Down and rearranging them.  I like to put the one I want at the top, then immediately following it with the “–warn below here–” tag, so I know definitively whether I’m getting my #1 choice.

But how do I know which ciper to choose?

Thats a good question, and I didn’t know either.  I did some extremely quick googling and I didn’t get a very definitive answer in the 2 or 3 pages I landed on, but I did find a nice command to run a benchmark on your local system so you can find out for yourself.  The command was:

openssl speed -engine padlock -evp *ciper* 

Where *ciper* is replaced by the name of the cipher you wish to test.  Executing this command starts an OpenSSL script which runs through the algorithm on locally on your computer, measuring the number of computations it can perform per second.

I extended this command with a simple tweak that allowed me to loop through the script using mulitple different ciphers:

for ENC in aes-256-cbc bf bf-ecb rc4 rc4-40 bf-cfb bf-ofb des3 des ; do openssl speed -engine padlock -evp ${ENC} ; done

After executing this, I walked away for a little (probably takes less than 5 mintutes but I didn’t want to introduce any more variability by messing around during the benchmark) and when I cameback it has maybe 150 lines of output, about 15 for each ciper.

Being the quantitative dude that I am, I immediately threw the data into Excel and plotted the processing throughput (in KBps and given on the last line of each iteration) vs block size (given on the second to last line).

The results were really surprising.  Here’s the table I compiled:

Where the highlighted cells indicate maximum throughput for each column or blocksize.  Its pretty apparent from this that RC4 really flys, but the table above doesn’t do the improvement justice.  Lets look at the data plotted:

Note: The label on the vertical axis incorrectly states the units as KBps when they are, in fact, MBps.

(click for full-size)

Wow, that is really a tremendous difference between the two RC4 ciphers and the rest, more often than not doubling the throughput of their alternatives.

So with such a huge difference in performance, certainly the RC4 cipher is the default cipher in PuTTY, right?  Actually, no.  At least in my vanilla PuTTY installations, RC4 (AKA Arcfour in PuTTY) is fairly low on the list, only preferred over DES.

I’m not a cryptographer, and I’m not well versed on the differences between the ciphers certainly not well enough to give any informed opinion on which cipher to choose from a security point of view, but from a sheer speed point of view, it would seem that RC4 would preferred.

Now our network is secured from the WAN side by a firewall on our router which we are trusting to prevent unauthorized access to the LAN side, so for us, encrypting SSH sessions that strictly live on the LAN side with a possibly sub-par cipher was acceptable if it provided the latency improvement that it looked like it would.  Your circumstances may differ and I urge you to consider all of them before you go changing settings.

Given that you’ve considered them, and you’re comfortable, lets go ahead and change the ciper priorities and see if we get any improvement.

Simply by clicking the cipher we want to move, then the Up / Down buttons, we were able to configure our priorities to this:

The idea here being that if, for some reason, we can’t establish a link with RC4, we’ll be notified.  We could then go back into the settings and move the “–warn below here–” line down a line and try again, hoping to connect with the Blowfish ciper, the second quickest cipher or otherwise receive a warning.

Results

Unfortunately, I don’t have any quantitative data to show the latency improvement, although I suppose you could demonstrate a bandwidth / throughput increase by doing a file transfer, however it is abundantly clear that there was, in fact, a huge latency improvement.  Things that caused annoying lag (eg clicking on the scrollbar to scroll quickly) showed a noticeable improvement.

As it is, without real data to show the improvement, you are left to experiment with the settings yourself, and, given you feel comfortable, I strongly encourage doing so — as it really seems to make a difference.

I’ll be sure to check back here when we receive the Gigabit hardware and present a before and after look at our LAN transfer speeds.