Where scalar crypto accelerates one block for small cores, vector crypto encrypts many blocks at once — one AES block per element group across the vector — for the bulk throughput of TLS records, disk encryption, and packet processing on application and server cores.
| Contents & element group | |
|---|---|
| Zvbb — vector basic bitmanip | vbrev/vbrev8/vrev8, vclz/vctz/vcpop.v, vrol/vror, vandn, vwsll (widening shift-left). Superset of Zvkb. |
| Zvbc — vector carry-less multiply | vclmul/vclmulh (64-bit; needs Zve64x) — the GHASH multiplier, vectorized. |
| Zvkb — crypto bitmanip subset | The Zvbb subset cryptography needs: brev8/rev8, rotates, andn, vwsll, scan ops. |
| Zvkg — GCM/GMAC | vghsh (GHASH multiply-add), vgmul. 128-bit groups (4×32-bit, EGS=4). |
| Zvkned — vector AES | vaesef/vaesem (encrypt final/middle), vaesdf/vaesdm (decrypt), vaesz (add round key), vaeskf1/vaeskf2 (key schedule). 128-bit groups. |
| Zvknha / Zvknhb — vector SHA-2 | vsha2ms (message schedule), vsha2ch/vsha2cl (compression). SHA-256 (128-bit groups, both); SHA-512 (256-bit groups, Zvknhb only — needs Zve64x). |
| Zvksed / Zvksh — ShangMi | SM4 (vsm4k/vsm4r) and SM3 (vsm3me/vsm3c). |
| Zvkt + composites | Zvkt: data-independent latency for the bitmanip/clmul instructions. Zvkn/Zvknc/Zvkng (NIST + GCM/GMAC variants), Zvks/Zvksc/Zvksg (ShangMi). |
Two contracts to note. Latency: the crypto-specific instructions (AES/SHA/GCM/SM) are intrinsically data-independent — no Zvkt needed; Zvkt only extends that to the bitmanip/clmul instructions, and is decoupled from scalar Zkt. Dependencies: Zvknhb and Zvbc (256-bit and 64-bit element work) need Zve64x; everything else needs only Zve32x.
Hardware Designer Notes
Vector crypto is scalar crypto’s SBox multiplied by the lane count: the area scales with throughput, and the design problem is feeding enough blocks (element groups) per cycle to keep the replicated SBoxes busy. The pages ahead cover each algorithm’s instructions; the hardware is the u32 datapath, widened.
Minimal Linux-boot hart MUST
- Replicate the scalar-crypto SBox/GF datapath per lane-group so one round instruction advances VLEN/128 blocks; keep latency data-independent across ALL lanes (no early-out)
- Enforce the EGS-multiple constraints on vl and vstart, and the Zve64x dependency for SHA-512/clmul
- Implement .vv (per-group key) and .vs (broadcast one key group) forms — CTR-mode AES needs .vs
MAY simplify / trap-and-emulate
- Skip vector crypto for a Linux-boot v1; add it when bulk-crypto throughput (kTLS, dm-crypt) matters — RVA23 lists it optional atop V
- Concatenate 32-bit elements across registers to form 128-bit groups when VLEN < 128 (the spec permits it)
Check yourself — vector crypto overview
1.How does vector crypto's performance model differ from scalar crypto's (u32)?
2.What is an element group, and why must vl be a multiple of EGS?
3.Which vector-crypto instructions must have data-independent latency, and how does that relate to Zkt/Zvkt?