Bugzilla – Bug 5774
ctccommon.derive_key is 750 times slower on Python 2.4 (without hashlib)
Last modified: 2016-04-12 12:27:44
You need to
before you can comment on or make changes to this bug.
We got a report about session startup in ThinLinc being slow on CentOS 5, so we
investigated. It seems that the derive_key function from ctccommon is the
function that's taking a whole lot longer with older Python versions. Python
2.4 does not have hashlib, so it uses a pure-Python implementation of sha512.
The derive_key function was introduced in bug 5607.
The reports were saying that this caused session startup to be so slow that
some clients timed out.
Here's some timing data from two more-or-less equal virtual machines (quad-core
x86_64, 4GB RAM) running on the same VMware server.
> CentOS 7:
> $ python -V
> Python 2.7.5
> $ python derive_key_bench.py
> derive_key(master, salt, 64) = 0.02 seconds
> derive_key(master, salt, 128) = 0.02 seconds
> derive_key(master, salt, 256) = 0.02 seconds
> derive_key(master, salt, 512) = 0.02 seconds
> CentOS 5:
> # python -V
> Python 2.4.3
> # python derive_key_bench.py
> derive_key(master, salt, 64) = 15.21 seconds
> derive_key(master, salt, 128) = 15.36 seconds
> derive_key(master, salt, 256) = 14.74 seconds
> derive_key(master, salt, 512) = 14.68 seconds
This should not normally be a problem as the default master key doesn't need
stretching, but a bug caused it to be anyway. This has now been fixed.
Another issue was that the key stretching was a lot slower than originally
expected. A master key of more than 22 bytes caused the CPU time to double. My
initial test machine was also apparently much faster as it executed the same
Python code in half the time compared to chavez.
So in summary, current use will not use key stretching and will be very fast.
If we use stretching in the future then we can expect delays in the order of
10-20 seconds on systems with Python 2.4. Hopefully we've raised the
requirements by then.
Logins on CentOS 5 no longer have slowdowns with build 5007.