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.
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.
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.
while [ $COUNTER -lt $E ] ;
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
# and for the ctr mode we would use the following
while [ $COUNTER -lt $E ] ;
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
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.
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
cat /etc/ssh_config | grep iphers
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# ken's cipher pick
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;
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.
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
Freelance Network & Security Engineer
kfelix ***at*** hyperfeed ***dot** com
=( O O ) =