AESKEYGENASSIST

AESKEYGENASSIST does the non-linear part of one step of the AES key expansion; the program does the rest with shuffles and XORs. From dwords 1 and 3 of its source it makes, for each, SubWord (every byte through the AES S-box) and RotWord of that XORed with the round constant from the immediate, and writes the four results to the destination’s dwords 0 to 3. Bits 128 and up of the register are kept; VAESKEYGENASSIST, the VEX form, clears them.

One step of AES-128#

With the last round key in a register, aeskeygenassist t, k, rcon followed by pshufd t, t, 0FFh puts RotWord(SubWord(w3)) XOR rcon in every dword. The new key is the old one XORed with itself shifted left by 4, 8 and 12 bytes (three PSLLDQ and PXOR pairs), and then with t, for AESENC to use. With FIPS 197’s example key 2B7E1516 28AED2A6 ABF71588 09CF4F3C and rcon 01H, w3’s bytes 09 CF 4F 3C become 8B 84 EB 01, and the first word of the next key is A0FAFE17, as the standard lists. AES-256 alternates this with a step that takes dword 2 (PSHUFD 0AAh), SubWord without rotation, with rcon 0; dwords 0 and 1 serve schedules whose last word sits in dword 1. Zen 5’s five recorded cases, with FIPS 197 round keys among the sources and the immediates 0, 1, 36H, 80H and FFH, agree with the Operation section.

The immediate must be a constant#

The round constant is an imm8, so _mm_aeskeygenassist_si128(k, r) needs a compile-time r: GCC 14 and Clang 23 reject a variable, and a key expansion is written out round by round (both compilers at -O2 emit exactly AESKEYGENASSIST, PSHUFD and the PSLLDQ and PXOR chain per round). It needs -maes or an -march that has AES, as AESENC does.

Intel’s optimization manual offers a loop instead (Section 6.10.2, Example 6-45): broadcast RotWord of w3 with PSHUFB and run AESENCLAST with the round constant in every dword as its key, shifting it left by one each round. With four equal columns ShiftRows changes nothing, so the round amounts to SubBytes and the XOR. The manual suggests it because AESKEYGENASSIST was slower than AESENC on Sandy Bridge. AMD’s Zen 5 guide gives AESKEYGENASSIST the same latency as AESENC, four cycles, two per cycle.

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

x1 = sub_word(src2.d[1])           # SubWord: each byte
x3 = sub_word(src2.d[3])           # through the S-box
xmm1.d[0] = x1
xmm1.d[1] = ror(x1, 8, 32) ^ imm8  # RotWord turns byte 1
xmm1.d[2] = x3                     # into byte 0; imm8 is
xmm1.d[3] = ror(x3, 8, 32) ^ imm8  # zero-extended
# bits 128 and up of the register are unchanged

Operands

Flags

None: XED records no flag that the forms test or change.

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

All forms

SSE_TYPE_4

Attributes

What else XED records about the forms. How to read.

Memory forms

aligned memory operand

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to AESKEYGENASSIST, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More AES-NI instructions

• AESDEC
• AESDECLAST
• AESENC
• AESENCLAST
• AESIMC
• VAESDEC
• VAESDECLAST
• VAESENC
• VAESENCLAST
• VAESIMC
• VAESKEYGENASSIST