[stunnel-users] help - SSL bandwidth overhead with using different ciphers

Fri Jul 30 18:50:17 CEST 2010

Hello,

In this case, I believe you should expect different results in speed, due to the 
internals of each cipher
and the computations needed to execute the encryption. Consider for instance the 
difference 

between stream ciphers (RC4) and block ciphers (AES). Also the modes of 
operation 

(ECB/CBC/CTR) all those factors have an impact on performance.

However, your observation about new processors making things faster is very 
true. A lot of implementations have tried to parallelize the encryption to take 
advantage of multicore processors. Intel has just added AES to its instruction 
set for new processors 

(AES-NI) so it is possible that the differences you find are not that big 
anymore.

I would suggest comparing RC4 with 3DES to see what your results are. Those are 
in my experience the fastest and slowest ciphers respectively. See what your 
results are with those.

I'm not an expert but I hope this ideas help at least to enhance the discussion.

Thank you

 -----------------
Leandro Avila

----- Original Message ----
From: Slim Ben Mahmoud <slim.ben.mahmoud at recherche.enac.fr>
To: stunnel-users at mirt.net
Sent: Wed, July 28, 2010 10:46:57 AM
Subject: [stunnel-users] help - SSL bandwidth overhead with using different 
ciphers

Dear SSL experts,

In order to assess the performances of an adaptive security algorithm using SSL, 

I need to measure the network overhead induced by the establishment of SSL 
tunnels.

The experiment aims to measure the bandwidth consumptions (or throughputs) when 
SSL tunnels are established using the different ciphers implemented in Stunnel 
(AES256-SHA or RC4-SHA for instance). Do you think that I have to expect a 
different throughput when I use different ciphers for every tunnels or the 
overhead is the pretty much the same? In fact, the first results show no 
difference between the throughputs no matter the cipher I use.

I know that SSL overhead is traditionally measured in delay or latency because 
of the handshake phase (the encryption process time is negligible on the new 
CPUs) but this is not what i want to show.

I hope that my request is enough clear, let me know if it is not the case.

Best regards.

--Slim