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@xxxxxxxxx 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/crypto_openssl_mgt.c?ref_type=heads#L382 > > > > 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Attachment:
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays