Cipher.types & CBC vrs CTR speed bakeoff

CBC vrs CTR, 3des vrs AES  , so many choices are you confused ?


In crypto and dealing with  plain.text--2--cipher.text, we are challenged into what mode to use and what cipher type to use.

All encryption function trys to accomplish the same the goal. We take some type of  plain.text  and encrypted it.  And then on the opposite end, we  take the  cipher.text and de-encrypted it back to plain.text using the same cipher and encryption method.

Both CBC ( Cipher Block Chaining ) vrs  CTR ( Counter Mode ),  provides differences, some minor in overall performance, and the functions and how it process a block of data is different. In this post we will use a simple bash script with a while function, execute a ssh transfer & than  measure  the performance numbers between the 2 mode. You can go farther and compare the difference between ciphers , which we will do a simple and quick test.

e.g
3des vrs aes128 
aes128 vrs 192 
aes 192 vrs 256
and so on ...........


1st I wanted to make reference to another  blogger on his thoughts with cryptography  and with regards to these modes. His blog has some very good information about the 2 differences between CBC and CTR modes.

http://johnx.blogspot.com/2010/10/aes-cbc-or-aes-ctr-mode.html


In our example, we will compare  various ciphers & modes, while  using ssh. We will try to keep all variable the same , by not relying on any disk-io, and while using the "loopback" interface to rule out any network related issues, and as to not askew our data results. All tests results produced here was on a relatively idle host and all cpu being available for the benchmark.

The goal for establishing  a benchmark, is to take  a equal set number of samples,  and  by using the 95th percentile and/or averaging. This would be our based number for cipher xyz and it's  effective transfer rate.

A few thoughts before we continue,  "why would we care on any performance number or gains ?"


Will I would use a teaching , that  my Dad taught me many, many decades ago,

I was walking along a street and seen a penny on the sidewalk. I didn't pick it up since it was only 1 penny. My dad asked me ; "why ?"

I told him it was  just only 0.01cents,  and it was not going to get me much if anything.

He's come back was; "yes it's only 0.01ct now, but want if you found 99 more pennies tomorrow?"

So in  encryption we need to look at it in the same method, any savings and over a course of time or duration, can make a big difference in the long run.

1st here's the script that we would use to execute our transfer of data for the samples that we will use in simple graphing and representation.

#!/bin/bash
#
#
E=100
#
COUNTER=0

while [ $COUNTER -lt $E ] ;
do
  echo " Testing Cipher Block Chaining Mode "
  dd if=/dev/zero bs=1m count=50 | ssh -i ~kenfelix1/.ssh/id_rsa.pub -o "Compression no" -c aes128-cbc 127.0.0.1 cat - > /dev/null
  sleep 1;
   let COUNTER=COUNTER+1

done
#
#
#

#  and for the  ctr mode we would use the following
#
#
#
while [ $COUNTER -lt $E ] ;

do
  echo " Testing  Counter Block Mode "
  dd if=/dev/zero bs=1m count=50 | ssh -i ~kenfelix1/.ssh/id_rsa.pub -o "Compression no" -c aes128-ctr 127.0.0.1 cat - > /dev/null
  sleep 1;
   let COUNTER=COUNTER+1

done



This above script will take 50megs of data (all zeros ) and transfer them thru ssh using the cipher  selected. We will not use any compression,  and to speed things up,  I'm  using my authorized_keys, so I will not be prompt for login information. The variable "E" will be the number of samples that we would execute.

The data that's being sent will generate a output similar to the following;

50+0 records in
50+0 records out
52428800 bytes transferred in 4.220085 secs (12423636 bytes/sec)

So the output of the bytes /per-second , will now be  extracted and using excel  or some other method, we will remove the top 5 and average the reminding  values or just use the 95th percentile to measure out the achieved transfer rate.

This style of testing,  is more accurate if we using more samples and/or long data sizes. You will easily find that your performance  rates will vary by the type of cipher used.

(e.g)

Arcfour for example is typically faster than  blowfish or AES

while 3des CBC is typically a bad performer

The difference for cipher types that use both cbc and ctr could vary based on the system and cpu



Once you find a cipher combo that provides the best performance, you could  set your sshd config to allow just that  cipher

e.g

cat /etc/ssh_config | grep iphers
#   Ciphers
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# ken's  cipher pick
Ciphers aes128-ctr
#

And if you want your local client machine to use that cipher as it's Default and all of the time you could do the following;



e.g

echo "Ciphers aes128-ctr > ~./.ssh/ssh_config

Here's example of how  you test for comparison data. I test the following ciphers plus arcfour128.

In the above files we found out that 3des-cbc was the worst performer. All testing was done a on macbookair and the outcome would be greatly effected by cpu types.

graph data:

I advise you to play with cipher types regardless if it's  for SSH, Website ( SSL/TLS)  or IPSEC/SSL vpn, and conduct your own benchmark & with traffic transfers to find the best  preferred cipher and  mode type.

NOTE: SSH v1 is horrible with transfer rates

Ken Felix
Freelance Network & Security Engineer
kfelix ***at*** hyperfeed ***dot** com

    ^    ^
=( O O ) =
       o
       ~