Are AES-NI crypto instructions used by my Tor (relay) server?

Question

I have a server with Linux Debian 8.4, running a relay.

I read that AES-NI could improve the performance of my relay. Or at least, less stress the CPU by crypto operations.

Proof of AES-NI detected by the system:

$ grep aes /proc/cpuinfo > /dev/null; echo $?

with the result of 0, which means my CPU does support it.

---

I read that it depends on OpenSSL package version, so:

$ apt-cache policy openssl

openssl:  
Installed: 1.0.1k-3+deb8u5  
Candidate: 1.0.1k-3+deb8u5  
Version table:  
*** 1.0.1k-3+deb8u5 0  
      500 http://security.debian.org/ jessie/updates/main amd64 Packages  
      100 /var/lib/dpkg/status

Tor version is:

$ tor --version

Tor version 0.2.7.6 (git-605ae665009853bd).

---

How do I ensure or check if Tor actually uses AES-NI CPU instructions directly or indirectly?

Answer 1

It depends:

https://gitweb.torproject.org/tor.git/tree/src/common/aes.c#n44

(Link has been removed, I've been unable to find it in the archive, maybe someone else will.)

on if the OpenSSL it was built against supports it.

---

As you're using OpenSSL 1.0.1 it should be in use, see torservers documentation.

Actually directly confirming that OpenSSL is using AES-NI seems like a trickier subject.

Answer 2

First to mention, I am running my relay from home, so I have physical access to it, but if you don't, always be prepared for the worst - have a backup of your relay keys, and a backup of your configuration before actually doing any big changes. This answer might contain changes that could lead to your relay operation disruption.

---

Updated 2019-Mar-07

---

In the recent Tor Relay Guide I've found

It is recommended to use CPUs with AESNI support (that will improve performance and allow for up to about ~400-450 Mbps in each direction on a single tor instance on modern CPUs). If the file /proc/cpuinfo contains the word aes your CPU has support for AES-NI.

---

Additional info found on ArchWiki

If # cat /proc/cpuinfo returns that your CPU supports AES instructions and # lsmod returns that the module is loaded, you can specify HardwareAccel 1 which tries "to use built-in (static) crypto hardware acceleration when available", see http://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration

---

Checking your setup: HW + OS

1. Find, find if your CPU supports AES-NI, with:

   $ grep aes /proc/cpuinfo > /dev/null; echo $?
   

   where 0 means your CPU does support it; and 1 means it does not.

2. Second, find if the module for AES-NI is loaded, with:

   $ lsmod | grep -i aes
   
   aesni_intel           200704  1
   aes_x86_64             20480  1 aesni_intel
   crypto_simd            16384  1 aesni_intel
   cryptd                 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
   glue_helper            16384  1 aesni_intel
   

---

Checking your setup: Software

1. OpenSSL must be version 1.0.1 or above, please check yours, with:

   $ openssl version
   

   Example output:

   OpenSSL 1.1.1a  20 Nov 2018
   

2. Tor must be version > 0.2.2 (unofficial claim, changelog), please check yours, with:

   $ tor --version
   

   Example output:

   Tor version 0.3.5.8.
   

I recommend you stay up-to-date in all circumstances.

---

Here I can actually answer my question: Yes, indeed, if you fulfill the requirements above, Tor performance can be greatly improved by enabling AES-NI instructions use. Please follow the below chapter in order to enable AES-NI use.

---

Enabling the use of AES-NI instructions

Settings option: HardwareAccel which can be 0 or 1 (link to wiki).

If non-zero, try to use built-in (static) crypto hardware acceleration when available. Can not be changed while tor is running. (Default: 0)

So, stop your relay with:

# systemctl stop tor.service

Add to Tor global settings file:

/etc/tor/torrc

This line, and make sure it is not there yet, with your favorite text editor:

HardwareAccel 1

Finally, you can start your Tor relay / bridge, with:

# systemctl start tor.service

You are done now. Either your relay / bridge will be faster, or the CPU will not be stressed as much.

---

VPS (Virtual Private Server) without the aes flag passed workaround

There is also a way to force OpenSSL AES-NI usage on a VPS without the aes CPU flag passthrough for Tor. To do so, I would proceed like this:

1. Run normal OpenSSL benchmark, for example:

   $ openssl speed -elapsed -evp aes-128-gcm
   

2. Run it with a special flag, and simply check if it is multiple times faster:

   $ OPENSSL_ia32cap="+0x200000200000000" openssl speed -elapsed -evp aes-128-gcm
   

If it was way faster in your case, then it proves your VPS provider does not allow passing the aes CPU flag into your Virtual Machine.

---

You can do the following, which you will have to repeat with each Tor upgrade:

1. Stop Tor service, and edit the following file with your favorite text editor:

   /etc/init.d/tor
   

2. Right after the first line, which stands:

   #! /bin/bash
   

   Add this line and start the Tor service again.

   export OPENSSL_ia32cap="+0x200000200000000"
   

More detailed info can be found here, I have re-written the most important parts only, so you should read it too.

Not only your relay / bridge might be faster, your VPS provider will actually be happy for you to use less of the CPU time!