Bug 5774 - ctccommon.derive_key is 750 times slower on Python 2.4 (without hashlib)
Summary: ctccommon.derive_key is 750 times slower on Python 2.4 (without hashlib)
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.5.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.6.0
Assignee: Pierre Ossman
URL:
Keywords: derfian_tester, relnotes
Depends on:
Blocks:
 
Reported: 2016-01-18 17:08 CET by Karl Mikaelsson
Modified: 2016-04-12 12:27 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Karl Mikaelsson cendio 2016-01-18 17:08:57 CET 
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
Comment 3 Pierre Ossman cendio 2016-01-19 17:23:40 CET 
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.
Comment 4 Karl Mikaelsson cendio 2016-01-20 10:07:21 CET 
Logins on CentOS 5 no longer have slowdowns with build 5007.
Note You need to log in before you can comment on or make changes to this bug.