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

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 (git-605ae665009853bd).

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

  • Given the packages and version numbers involved, Tor is pretty definitely using AES-NI, but i'm not sure how to prove it... Commented May 31, 2016 at 20:19
  • I wasn't mistaken. HardwareAccel is for a different type of feature. Commented Mar 8, 2019 at 4:45
  • HardwareAccel is for dynamically loading engines. OpenSSL >= 1.0.1 enables AES-NI by default and does not need an engine.
    – nobody
    Commented Mar 9, 2019 at 11:12
  • By eyeballing the source code: here we actually use HardwareAccel, calling here and comes down to here, which calls crypto_openssl_init_engines if useAccel > 0 (which is HardwareAccel == 1 if I am correct) and does nothing if not.
    – nobody
    Commented Mar 9, 2019 at 11:22

2 Answers 2


It depends:


(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.


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

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:


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:

  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!

  • I’m pretty sure the “HardwareAccel” flag doesn’t enable AES-NI (it’s used for something else), but I’ll try to remember to look into this later.
    – Steve
    Commented Mar 8, 2019 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .