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@recherche.enac.fr To: stunnel-users@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