Please read the code, not only Tor's code, but also OpenSSL's code.
Yes, AES is not displayed as engine itself, however, it still does not seem to use aes-ni instructions unless told to initialize engines via the code I deducted.
If this proves anything, I ran an Exit Relay in 2013 before my host forced me to switch to a Guard one because of excessive abuse, and even though my VM supported aesni instructions, OpenSSL would not actually use them until I added the config parameter, the peak CPU usage (single core) dropped from 88-95% avg to around 23% avg once I added it.
Maybe some developer can comment on the deeper workings of OpenSSL and Tor, and terminology might get weird between the Tor and OpenSSL (both very big code-bases).
Also, regarding the e-mail, I post regularly on here and tor-dev, so no worries :)
Let's just end this pointless discussion here, I will do some more research the next few days because I actually want to know, but to me everything seems pretty clear (from the code I've YET SEEN, not the one I DID NOT YET SEE).
Peace, friend.
P.S: I included the tor-dev mailing list to my recipients, they should be more knowledgeable, I am just an employed C/C++ programmer on mostly Windows and POSIX-compatible systems, with a little over 15 years of experience, with some reverse engineering experience on both PE and MACHO binaries (x86 & x64).
On Mon, 18 Dec 2023 15:58:52 +0000 George Hartley hartley_george@proton.me wrote:
I had a quick look at the manual, and it stated:
HardwareAccel 0|1
If non-zero, try to use built-in (static) crypto hardware acceleration > when available. Can not be changed while tor is running. (Default: 0)
A quick look at the source code tells me that Tor relies entirely on OpenSSL.
The call-chain here is as follows:
crypto_set_options first determines whether to enable any available OpenSSL engines based on if the variable mentioned above is non-zero or if an accelerator name has been set:
const bool hardware_accel = options->HardwareAccel || options->AccelName;
This bool is then passed into crypto_global_init, where it is the first argument, fittingly named "useAccel".
useAccel is then passed into crypto_openssl_late_init, where if HardwareAccel is the default (0) or no engine name has been specified, OpenSSL will make no attempt to load any acceleration engines.
Here is a permalink to that last relevant function in the call chain:
https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/lib/crypt_ops/cry...
So yes, I think it is pretty safe to assume that if you do not set either configuration option, no OpenSSL engine will be used.
Thank you for questioning me though, thanks to you I learned some more about Tor's inner workings, and you hopefully too :)
It is not entirely clear to me what conclusion you came to after this research. If you mean that HardwareAccel is needed, I would still disagee.
If I'm not mistaken the AES-NI support is implemented in OpenSSL not via an "engine" that you have to "use", it is just built-in internally on some deeper level. For a proof you can run "openssl engine" in the console of any AES-supporting machine, and you will not see any loadable engines there, aside from rdrand, which is unrelated, and "dynamic" which just means it can load some acceleration engines if it had any. And for instance VIA Padlock would show up as "padlock" in that list.
Please use reply to all the mailing list. Sorry for bringing out your mail into the public, but it didn't seem to be strictly private in any case.
-- With respect, Roman _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays