mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 14:23:30 +01:00
9814019a54
This shaves about 7% off our per-cell AES crypto time for me; the effect for accelerated AES crypto should be even more, since the AES calculation itself will make an even smaller portion of the counter-mode performance. (We don't want to do this for pre-1.0.0 OpenSSL, since our AES_CTR implementation was actually faster than OpenSSL's there, by about 10%.) Fixes issue #4526.
17 lines
880 B
Plaintext
17 lines
880 B
Plaintext
o Code simplification and refactoring:
|
|
- Unconditionally use OpenSSL's AES implementation instead of our
|
|
old built-in one. OpenSSL's AES has been better for a while, and
|
|
relatively few servers should still be on any version of OpenSSL
|
|
that doesn't have good optimized assembly AES.
|
|
|
|
o Major features (AES performance):
|
|
- Use OpenSSL's EVP interface for AES encryption, so that all
|
|
AES operations can use hardware acceleration (if present).
|
|
Resolves issue #4442.
|
|
- But only use the EVP interface when AES acceleration is enabled,
|
|
to avoid a performance regression. Resolves issue #4525.
|
|
- When using OpenSSL 1.0.0 or later, use OpenSSL's counter mode
|
|
implementation; it makes AES_CTR about 7% faster than our old one
|
|
(which was about 10% faster than the one OpenSSL used to provide).
|
|
Resolves issue #4526.
|