Does AES-NI offer better side-channel protection compared to AES in software? Also, it would be great of you could provide according references in your answer.


3 Answers 3


Yes, AES-NI was specifically designed to be constant-time and thus offers better side-channel protection than (some) software implementations. Note however that these day there exist quite fast side-channel resistant software implementations for AES, which are in-use by the better crypto libraries. AES-NI mainly offers a speed advantage over these implementations.

From the Intel® Advanced Encryption Standard (Intel® AES) Instructions Set Whitepaper:

The AES instructions are designed to mitigate all of the known timing and cache side channel leakage of sensitive data (from Ring 3 spy processes). Their latency is data-independent, and since all the computations are performed inter nally by the hardware, no lookup tables are required. Therefore, if the AES instructions are used properly (e.g., as in the following code examples) the AES encryption/decryption, as well as the Key Expansion, would have data-independent timing and would involve only data-independent memory access. Consequently, the AES instructions allow for writing high performance AES software which is, at the same time, protected against the currently known software side channel attacks

  • 4
    $\begingroup$ "and since all the computations are performed internally by the hardware, no lookup tables are required" ... that's actually a weird passage. You can use or forgo tables in either hardware or software. $\endgroup$
    – Maarten Bodewes
    Feb 4, 2017 at 16:27
  • 2
    $\begingroup$ @MaartenBodewes Hardware implementations usually use boolean logic to save gate area, so it likely was lapsed from the technical writer's mind. AFAIK most FPGAs use table implementations. $\endgroup$ Feb 5, 2017 at 7:08
  • $\begingroup$ @user3201068 Maarten didn't state anything else, making your comment somewhat superfluous. $\endgroup$
    – e-sushi
    Feb 5, 2017 at 11:56
  • 3
    $\begingroup$ Also having tables is not a problem per-se, what is a problem is having tables in memory that is not constant-time. $\endgroup$ Feb 5, 2017 at 13:10
  • $\begingroup$ It likely meant that no lookup tables are required in the cache, which is what side-channel attacks against AES often abuse. $\endgroup$
    – forest
    Mar 7, 2018 at 6:53

With regards to timing-based side channels (those that can potentially be exploited remotely, as opposed to, say, power analysis), the AES-NI opcodes are constant-time. See for instance Intel Intrinsics Documentation, that describes the C-like function that can be used to leverage these opcodes: the opcode throughput and latency are fixed, which means "constant-time".

Now, of course, this is better than "software implementations" only insofar as:

  • The opcodes are used properly; e.g., if doing CBC decryption in the context of SSL/TLS, even if the AES itself is handled in a constant-time way, the CBC padding processing can also leak substantial amounts of secret information.

  • The "software implementations" that you compare with are not themselves constant-time. See for instance the Käpser-Schwabe implementation of AES-CTR, that leverages to SSE2 register for a remarkably fast and constant-time code; or, in "plain C", my own code.

The really good point of the AES-NI opcodes is that they provide very good performance. Measures speak for themselves:

BearSSL speed/size benchmark for AES on x86_64

The AES-NI code in CBC decryption and CTR modes could be made even faster; this code processes four blocks in parallel, but the underlying CPU would be more comfortable with eight parallel blocks; OpenSSL achieves more than 4 GB/s on the same machine (but it hardly matters for SSL/TLS, since the HMAC or GHASH for integrity check will be the bottleneck).

So we can say that the AES-NI opcodes offer as good as you can get protection against side channels, in absolute terms; and they are much better than anything else on the same platform when evaluated relatively to the achieved performance. It is common to see trade-offs between security and performance in cryptographic algorithm implementations.

  • $\begingroup$ "The AES-NI opcodes offer as good as you can get protection against side channels"; actually, I've heard complaints that the AES-NI instructions might not give sufficient protection against DPA-style attacks. I have not evaluated these complaints to see if they have a point, but I have heard them... $\endgroup$
    – poncho
    Feb 4, 2017 at 16:38
  • 1
    $\begingroup$ @poncho I am voluntarily restricting myself to time-based side channels. It can be assumed that on any platform that ressembles a PC, secrets probably bleed all over the place when considering power analysis. $\endgroup$ Feb 4, 2017 at 16:53
  • $\begingroup$ Actually, Cryptography Research is selling AES implementations that they claim are resistant to power analysis (and similar side channels). I would agree with you about an AES implementation that wasn't specifically designed by a person with deep understanding of side channels... $\endgroup$
    – poncho
    Feb 4, 2017 at 18:13
  • $\begingroup$ In hardware, you can just double all of the registers to dual-rail encode everything. It means there's no power information lost because you see symmetry in the device current. I have no idea why this is not generally done except for the fact that you double the area. $\endgroup$
    – b degnan
    Feb 5, 2017 at 1:27
  • $\begingroup$ @bdegnan It is likely because modern IBM-style PCs are not designed with security against physical attacks in mind at all. For people who need this property, they tend to buy hardware with NATO SDIP-27 certification. It's easier to simply clean your entire power supply of EMSEC issues than it is to design the CPU to be immune to power analysis attacks. $\endgroup$
    – forest
    Mar 7, 2018 at 6:58

In addition to the good answers by Thomas Pornin and SEJPM, I will also add a hypothetical downside related to side-channel attacks and AES-NI: nearly undetectable targeted hardware attacks.

It's fairly trivial to write a backdoored CPU that will run arbitrary code when a certain data pattern is triggered. This is hard to detect in the hardware and can be remotely triggered as long as you can get data into the affected CPU (e.g. by sending a IP packet).

However, this backdoor is merely a door, and requires a payload to actively exploit. This means that the actual exploit runs in software, and is easily exposed. It leaves a big smoking gun, and it requires the payload to work on an unknown machine.

But the AES-NI instructions allow for a new, incredibly targeted attack. Simply by modifying a chip to store the last n keys passed to AES-NI instructions you have a nearly undetectable key escrow, allowing you to get out the keys at a later time (e.g. by using a certain data pattern that gets replaced with the key). This is incredibly stealthy, and may work for years before it is actually detected.

  • $\begingroup$ I'm having problems why AES-NI necessarily makes this easier. This exploit comes in two phases; one is something that detects that an AES key is in use (and stores it internally in the CPU); the second phase is exploit code that extracts the contents of that secret location, and returns that. AES-NI would be involved only in the first phase (and you could equally as well have the CPU detect the instructions involved in, say, the OpenSSL AES key expansion logic. You highlight the second phase; how would AES-NI make that easier? $\endgroup$
    – poncho
    Feb 5, 2017 at 12:05
  • $\begingroup$ "and you could equally as well have the CPU detect the instructions involved in, say, the OpenSSL AES key expansion logic" this is not feasible to do while maintaining a well-functioning CPU that looks normal under inspection with a microscope. It can also lead to a lot of false positives and/or missed opportunities. The first phase is a lot harder than you think to do stealthily. But you are accurate in that once the key has been put into the CPUs hidden escrow, phase 2 has nothing to do with AES-NI anymore. $\endgroup$
    – orlp
    Feb 5, 2017 at 12:44
  • $\begingroup$ I actually didn't disagree with how difficult phase 1 is (although I wouldn't worry about inspection by a microscope; instead, I would worry about the stability and uniqueness of the AES code; I'm also not certain that AES-NI makes it quite as easy as you make out); I was chiefly objecting to your second paragraph, which seemed to claim that phase 2 was difficult (and actually, I don't believe it is, at least when compared to phase 1, even with AES-NI). $\endgroup$
    – poncho
    Feb 5, 2017 at 17:54
  • $\begingroup$ @poncho My second paragraph is intended to convey the opposite. Are you perhaps confused with "this is hard to detect in the hardware"? I meant that the backdoor is hard to detect, not the pattern. $\endgroup$
    – orlp
    Feb 5, 2017 at 19:00
  • $\begingroup$ Actually, I miscounted; I meant the third paragraph, with "This means that the actual exploit runs in software, and is easily exposed"; actually, with a bit of cleverness, it's not that hard to hide it assuming the cooperation of the CPU manufacturer (hint: not all instructions are deterministic...) $\endgroup$
    – poncho
    Feb 5, 2017 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.