Module x86 

The x86-64 AES-NI backend.

What is and is not reimplemented here

Only the round function is accelerated. Key expansion stays in portable::Schedule, and this backend loads its output into SIMD registers. Expansion happens once per key and is not on the hot path, so a second implementation of it would buy nothing and risk a divergence — particularly for AES-192, whose SIMD key schedule is the fiddliest part of a typical AES-NI implementation.

Decryption uses the equivalent inverse cipher: the encryption round keys are passed through AESIMC and reversed at construction, which is what lets AESDEC run the inverse rounds in the same shape as the forward ones.

Safety

These functions are unsafe because #[target_feature] requires it: a caller must not invoke them on a CPU without AES-NI. The intrinsics themselves are safe once that feature is enabled in scope, so the only genuinely unsafe operations are the raw-pointer loads and stores — and those are the only things wrapped in an unsafe block.

Constant-time properties

AESENC and friends are single instructions with data-independent latency, so this backend is constant-time for the same reason the portable one is — and it never touches a lookup table at all.

Structs

Keys

AES round keys held in SIMD registers.

Constants

PARALLEL_BLOCKS

How many blocks the batch path processes at once.

Functions

ctr32_xor^⚠

XOR data with the CTR keystream starting at counter, advancing the counter’s last 32 bits big-endian and wrapping within them – GCM’s inc32 – eight blocks at a time.

decrypt_block^⚠

Decrypt one block in place.

encrypt_block^⚠

Encrypt one block in place.

encrypt_blocks^⚠

Encrypt a whole number of blocks in place, eight at a time.