I don't think this is necessary to make it use AES. It would use that
automatically. HardwareAccel is needed only to enable some external OpenSSL
acceleration engines, such as the defunct "VIA Padlock".
···
On Mon, 18 Dec 2023 10:03:01 +0000 George Hartley via tor-relays <tor-relays@lists.torproject.org> wrote:
lscpu | grep aes
If the command returns nothing, sadly your CPU does not support hardware AES
acceleration, or if you run your OS in a VM, then the VM operator likely did
not set "host" as CPU model.
If however the command does output a list of flags, with aes highlighted in
red (depends on SSH client), then you can safely add the following line to
your nodes configuration file:
> HardwareAccel 1
--
With respect,
Roman
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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.
···
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:
src/lib/crypt_ops/crypto_openssl_mgt.c · main · The Tor Project / Core / Tor · GitLab
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 
--
With respect,
Roman
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
My main point though: it would be an insanity and beyond belief, if Tor would
not use the universally-available AES-NI instruction sets on modern CPUs,
unless the user somehow knows to find and set a non-default config option.
Moreover, just recently in my experience leading to the message "[tor-relays]
Worse throughput with 0.4.8.x, on a slow CPU"[1] I tried ALL sorts of the
possible tweaks I could find, which included adding "HardwareAccel 1" to the
config (it was absent before), and it made no difference in CPU use.
[1] https://lists.torproject.org/pipermail/tor-relays/2023-December/021407.html
···
On Mon, 18 Dec 2023 16:57:37 +0000 George Hartley <hartley_george@proton.me> wrote:
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).
--
With respect,
Roman
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays