AES-NI (Hardware acceleration of symmetric AES encryption)

AES-NI is a set of processor instructions that perform the heaviest stages of AES directly in silicon. Instead of computing complex cryptographic math in software, consuming dozens of clock cycles per byte, the central processor processes a data block with a single fast machine command without delays and core overload.

The technology is used wherever transparent data protection is needed without performance loss. It is employed in full-disk encryption (BitLocker, FileVault, LUKS/dm-crypt), databases with TDE, IPsec VPN gateways, high-load web servers during TLS connection establishment, and in cloud infrastructures handling enormous volumes of secure traffic.

Typical problems are associated with instructions not being engaged due to incorrect selection of the cryptographic backend in libraries (OpenSSL without the EVP flag) or the use of slow software implementations in guest virtual machines without passthrough of the host processor capabilities. There is also a slight increase in CPU package power consumption under avalanche load and difficulties with isolated benchmarking of accelerated functions on multitasking systems.

How AES-NI works

The operating principle is based on the introduction of six new instructions to accelerate AES rounds and subkey generation. Four instructions (AESENC, AESENCLAST, AESDEC, AESDECLAST) perform a single encryption or decryption round, combining the SubBytes, ShiftRows, MixColumns, and AddRoundKey operations in a minimum number of clock cycles with pipelining. Two more (AESKEYGENASSIST and AESIMC) handle key expansion and inverse mix columns. Unlike accelerators such as ARMv8 Crypto Extensions, which often operate with registers combined with the NEON SIMD block, the Intel implementation uses a dedicated hardware core that does not block the execution ports of SSE vector units. Compared to purely software execution via substitution tables (S-Box), this not only increases throughput by 3–10 times but also completely eliminates vulnerability to side-channel attacks based on cache access timing, since data transformation occurs in closed logic without accessing RAM.

SSE (Simultaneous processing of multiple data with a single instruction)

AES-NI functionality

  1. Instruction set support. AES-NI implements hardware acceleration of AES block cipher operations in x86-64 processors. The set consists of seven instructions: four for encryption/decryption, two for key expansion, and one for multiplication in a finite Galois field.
  2. AESENC/AESENCLAST instruction format. The AESENC instruction performs one encryption round consisting of SubBytes, ShiftRows, MixColumns, and AddRoundKey. AESENCLAST performs the final round, excluding the MixColumns transformation. Both accept the state in an XMM register and the round key, returning the result in XMM.
  3. AESDEC/AESDECLAST instruction format. The decryption instructions work with an equivalent inverse round key. AESDEC performs InvShiftRows, InvSubBytes, InvMixColumns, and AddRoundKey. AESDECLAST completes the process, omitting InvMixColumns. The hardware pipeline processes a 128-bit state block with minimal latency.
  4. Key expansion: AESKEYGENASSIST. This instruction accelerates round key generation. It accepts the current 128-bit encryption key and the Rcon constant, computing the result of SubWord and RotWord operations on the low-order word. The result is placed into an output XMM register for subsequent software processing.
  5. Galois field operation: PCLMULQDQ. Although PCLMULQDQ is part of the CLMUL set, it is critical for AES-GCM authenticated encryption modes. The instruction performs carry-less multiplication of two 64-bit operands in the finite field GF(2), producing a 128-bit result. The hardware implementation executes in a few clock cycles.
  6. Execution atomicity. A key feature of AES-NI is the atomic execution of an encryption round. The processor eliminates side channels of data leakage based on execution time and power consumption at the microarchitectural level, as data transformation occurs in a fixed number of clock cycles without branching.
  7. Operating modes and pipelining. When using ECB or CBC encryption, AESENC instructions can be loaded sequentially without waiting, forming a software pipeline. The processor can deliver results with a throughput of one round per cycle, providing a multiple-fold acceleration of cryptographic operations.
  8. Clock cycles per round. For AES-128, the execution latency of a single AESENC instruction ranges from 4 to 8 clock cycles depending on the microarchitecture. Throughput is inversely proportional to latency and equals 1–2 clock cycles per instruction provided dense packing of independent data blocks in the pipeline.
  9. AES-192 and AES-256 processing. AES-NI instructions are independent of key length. For AES-192, the software layer applies 12 rounds; for AES-256, 14 rounds. Hardware acceleration affects only the computational part of the round, while dispatching the number of rounds remains the responsibility of the cryptographic library developer.
  10. CPUID flag check. Before using the instructions, the AES flag must be verified (bit 25 in ECX after CPUID.01H). In the absence of support, the core generates #UD (Invalid Opcode). Correct verification prevents abnormal termination of processes on processors without hardware acceleration.
  11. Integration with AVX and YMM registers. In microarchitectures with AVX support, AES-NI instructions operate on the lower 128 bits of YMM registers. The upper 128 bits are zeroed. This allows efficient mixing of encryption operations with vector data processing without penalties for switching SIMD register states.
  12. AVX (SIMD data processing with 256/512-bit registers)
  13. Key protection mechanism. Hardware execution prevents round key components from entering the cache memory as independent data. Internal byte permutations and table substitutions are implemented in transistor logic, which prevents cache-timing attacks typical of software S-Box implementations.
  14. CBC decryption optimization. During CBC mode decryption, AESDEC instructions perform InvMixColumns. Thanks to pipelining, processing of multiple blocks with overlap is possible, where dependencies on previous ciphertext are compensated by speculative execution and mixing of instruction streams.
  15. Integration into OpenSSL. The OpenSSL library, through the EVP API, automatically engages AES-NI upon flag detection. The execution path switches from table-based to vector-based, where the assembly core passes the state directly via XMM registers, minimizing the number of context saves.
  16. Usage in the Linux kernel. The Linux crypto subsystem (crypto API) contains driver modules aesni-intel and equivalents for AMD. The hardware implementation has higher priority than the software one. The skcipher interface provides asynchronous routing of calls to AES-NI instructions for disk encryption (dm-crypt).
  17. AES-GCM implementation. Combining PCLMULQDQ for computing the GHASH authentication tag and AESENC for encryption allows achieving processing speeds of more than 2–3 cycles per byte. Pipelining interleaves field multiplication and encryption rounds, effectively utilizing processor execution ports.
  18. Vector processing in XTS mode. For XTS-AES disk encryption, AES-NI is used for encrypting the tweak value and the subsequent AES block. Replicating the tweak via PCLMULQDQ and parallel processing of independent blocks in XMM registers (2/4 streams) yields an almost linear increase in throughput.
  19. Vector (Ordered storage of numbers in continuous memory)
  20. AMD microarchitecture specifics. AMD processors on Zen cores execute AESENC with a latency of 4 clock cycles and a throughput of 1 clock cycle. The hardware scheduler distributes instructions to a dedicated AES port, isolating the crypto load from competition with integer and floating-point operations.
  21. Intel Ice Lake and later specifics. The Sunny Cove microarchitecture added support for VAES (Vector AES), using 256-bit and 512-bit registers to process two or four AES blocks with a single instruction. This reduces the number of instructions per byte and decreases the load on the front-end decoder.
  22. Comparison with software implementation. Software AES without hardware support uses 4 KB substitution tables and is sensitive to first-level cache misses. AES-NI eliminates these misses, increases performance by 3–10 times, and makes execution time constant relative to input data.
  23. Impact on power consumption. The AES hardware block consumes significantly less energy per unit of encrypted data than decoding and executing hundreds of scalar instructions. This is critical for data centers with TLS loads, where the aggregate TDP reduction reaches several watts per socket.
  24. TDP (Project processor heat dissipation limit)

Comparisons

  • AES-NI vs Software AES implementation. AES-NI performs encryption rounds in hardware, integrating them into the processor execution pipeline, whereas the software implementation operates with substitution tables in RAM. This completely eliminates access-time leaks to the cache typical of S-boxes and radically reduces clock cycle costs per byte, increasing throughput.
  • AES-NI vs ARMv8 Cryptographic Extensions. The AES-NI set is implemented in the x86-64 architecture with dedicated XMM registers for parallelism, while ARMv8 extensions use the NEON file and instructions like AESE. The key difference lies in microarchitectural latency and mobile energy efficiency, where ARM offers comparable cryptographic strength with significantly lower heat dissipation for embedded systems.
  • ARM (Energy efficient execution of processor instructions)
  • AES-NI vs Intel SHA Extensions. AES-NI instructions are aimed exclusively at symmetric block encryption, performing AddRoundKey and MixColumns operations in a single cycle, whereas SHA extensions implement hashing according to SHA-1 and SHA-256 standards. Functionally they are orthogonal: the former ensure data confidentiality, while the latter accelerate the computation of message authentication codes and digital signatures without covering encryption operations.
  • AES-NI vs VIA PadLock. AES-NI is integrated into general-purpose Intel and AMD compute cores with support for AVX vector extensions, whereas PadLock is a dedicated security coprocessor on the VIA chip with an asynchronous interface. The PadLock solution historically appeared earlier, but AES-NI wins in throughput due to the absence of overhead for data transfer between separate processor blocks.
  • AES-NI vs GPU acceleration (CUDA/OpenCL). AES-NI operates directly within the main program execution thread with zero PCIe bus latency, whereas GPU acceleration requires explicit copying of data to and from video memory. Although the massively parallel GPU architecture provides theoretically higher peak performance, AES-NI dominates in scenarios with small data blocks due to negligible latency and the absence of CPU core idle time.
  • CUDA (Parallel computing on the graphics processing unit)

OS and driver support

AES-NI implementation requires explicit support from the operating system, which, through cryptographic APIs (CryptoAPI in Windows, Crypto Framework in Linux), provides applications with access to hardware-accelerated functions; kernel drivers do not manage these instructions directly, but the OS must save and restore the state of XMM registers (used by AES-NI instructions) during task context switching to ensure correct multitasking operation.

Security

Using AES-NI eliminates entire classes of side-channel attacks based on timing differences (timing attacks), since hardware execution of encryption rounds takes a strictly fixed number of clock cycles, independent of key or data values; furthermore, computations are isolated inside the processor and do not affect the cache memory with substitution tables, which prevents key leakage through cache state analysis (cache-timing attacks).

Logging

Information about AES-NI engagement is logged at the level of cryptographic libraries, not the processor itself: for example, OpenSSL checks CPUID flags at startup, recording the presence of AES-NI support in debug output, and the Linux kernel writes the corresponding capability flags (aesni) to the ring buffer, accessible via dmesg; direct tracing of the execution of individual AESENC or AESDEC commands with a hardware debugger is possible only with detailed profiling through performance counters.

Limitations

The AES-NI set accelerates only the AES algorithm and does not affect the performance of other symmetric ciphers; only key lengths of 128, 192, and 256 bits are supported, and instruction execution occurs exclusively on 128-bit blocks, so for authenticated modes (GCM) or stream modes (CTR), an efficient software wrapper is critically important; otherwise, the speed gain is negated by overhead for processing authentication tags or generating keystream.

History and development

AES-NI instructions were first introduced by Intel in 2008 on the Westmere microarchitecture and subsequently expanded with support in AMD processors starting with Bulldozer; the initial set included six commands for encryption rounds, key expansion, and inverse transformation, and in 2021, with the release of the Ice Lake microarchitecture, Intel added VAES (Vector AES) instructions operating on 256- and 512-bit registers for parallel processing of multiple data blocks at once.

Latest publications