[tor-relays] Declining Relay Usage

[George Hartley]

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 at 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/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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - hartley_george at proton.me - 0xAEE8E00F.asc
Type: application/pgp-keys
Size: 657 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20231218/24ca9f92/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20231218/24ca9f92/attachment.sig>