Software AES fallback indexes T-tables with secret-dependent state

The generic software AES encryptor selects entries from encT using bytes of the round state. Those bytes depend on both plaintext and the secret round key, so cache lines touched by the T-table reveal key-correlated information. This violates constant-time expectations whenever dispatch falls back to this implementation.

Vulnerable code

In cipher/rijndael.c, function do_encrypt_fn:

sa[0] = sb[0] ^ rk[0][0];
sa[1] = sb[1] ^ rk[0][1];
sa[2] = sb[2] ^ rk[0][2];
sa[3] = sb[3] ^ rk[0][3];

sb[0] = rol(encT[(byte)(sa[0] >> (0 * 8))], (0 * 8));
sb[3] = rol(encT[(byte)(sa[0] >> (1 * 8))], (1 * 8));
sb[2] = rol(encT[(byte)(sa[0] >> (2 * 8))], (2 * 8));
sb[1] = rol(encT[(byte)(sa[0] >> (3 * 8))], (3 * 8));

Why it matters

Exposure requires a platform without a selected constant-time hardware or bitsliced backend and a co-resident observer capable of repeated cache measurements. That excludes many modern deployments, but generic fallback code is precisely what runs on older or constrained systems. The source establishes secret-dependent addressing; a complete end-to-end key recovery was not reproduced in this review.

Proposed fix

Route fallback encryption to an existing constant-time implementation, or replace T-table rounds with a bitsliced/fixsliced or constant-time computed S-box design. Do not attempt to mask only individual indices. Add dispatch tests that force every backend, a static check forbidding secret-indexed encT use in the generic path, known-answer vectors, and a timing/cache regression benchmark across varied keys.