| Operation | In | |
|---|---|---|
| vaeskf1.vi | AES-128 key-schedule word: RotWord + SubWord + Rcon[imm] on each 128-bit key group — the round-number immediate selects the round constant. | Zvkned |
| vaeskf2.vi | AES-256 key-schedule: produces the next 128-bit key group from the previous two, with the round-number immediate. | Zvkned |
| vaesz.vs | AddRoundKey only — XOR the broadcast round-key group into every state group. The initial whitening before round 1. | Zvkned |
| vandn.[vv,vx] | Lane-wise vs2 & ~vs1 (or ~x[rs1]) — the Zbb AND-not, vectorized. Bit-slicing and GHASH helper. | Zvbb / Zvkb |
The key schedule vectorizes just like the rounds: vaeskf1.vi
expands all key groups in the vector at once, the immediate carrying
the round number so Rcon comes straight from decode. A full AES-128
schedule is ten vaeskf1.vi with immediates 1–10; AES-256 interleaves
vaeskf2.vi.
Hardware Designer Notes
Key expansion is cheap relative to the round datapath — a RotWord rotate, an SBox pass, an Rcon XOR — and vectorizing it means the schedule lives in registers, ready to broadcast. The design payoff is entirely in not re-expanding per block.
Minimal Linux-boot hart MUST
- vaeskf1/kf2: RotWord/SubWord (shared SBox) + Rcon-from-immediate + XOR-combine, per key group
- vaesz.vs: pure broadcast-key XOR, no substitution — keep it distinct from the round instructions
- vandn and the other Zvbb/Zvkb instructions get their constant-time guarantee from Zvkt, not intrinsically
MAY simplify / trap-and-emulate
- Share the key-schedule SBox with the round-instruction SBox array
- Precompute Rcon as a tiny ROM indexed by the immediate
Check yourself — AES key schedule & vandn
1.vaeskf1.vi takes a round-number immediate. Why is the round number an immediate rather than a register?
2.vandn.vv computes what, and where is it used in vector crypto?