[stunnel-users] help - SSL bandwidth overhead with using different ciphers
Leandro Avila
leandro.avila at ymail.com
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
More information about the stunnel-users
mailing list