Fast crypto instructions are useless if their timing leaks the key. Zkt is the architectural promise that a listed subset of instructions executes in time independent of their data operands — the “constant-time” contract that lets cryptographers reason about side channels.
| Rule | |
|---|---|
| A contract, not a feature | Zkt adds NO instructions. It restricts the timing BEHAVIOR of ones already present: a vendor needn’t implement every listed instruction, but any they do implement must be data-independent in latency. |
| The list | All Zk*/Zbk* crypto instructions, plus relevant I/M/C/B supporting instructions (logicals, shifts, rotates, add/sub, MULTIPLY) — the operations constant-time crypto actually uses. |
| The exclusions | Loads, stores, conditional branches, DIVIDE, and rarely-secret-processing instructions. |
| OoO freedom | Implementations may fuse, crack, or elide instruction sequences — provided every optimization is DETERMINISTIC (keyed on the instruction stream, never on operand values). |
| The honest caveat | Without Zkt attestation, even a bit-sliced (pure-boolean) cipher has NO timing guarantee — a value-dependent multiplier or an operand-keyed predictor would leak. |
Hardware Designer Notes
Zkt is nearly free on straightforward designs and expensive to retrofit onto aggressive value-speculating ones — decide early. The verification target is subtle: it’s not functional, it’s a timing property, so it belongs in your side-channel signoff (constant-time test vectors, dudect-style measurement), not the functional suite. This is the page that makes the whole crypto chapter trustworthy.
Minimal Linux-boot hart MUST
- If you claim Zkt: audit every listed instruction you implement for operand-value-dependent timing — early-out multipliers, data-gated shifters, and lazy normalizers all violate it
- Keep any instruction fusion/cracking keyed strictly on opcodes and architectural state, never on data values
MAY simplify / trap-and-emulate
- Claim Zkt on a simple in-order core almost for free — fixed-latency ALUs are naturally data-independent
- Skip Zkt if you never target constant-time crypto — but then the crypto instructions’ security guarantee is void, so most crypto-capable cores should attest it
Check yourself — Zkt constant-time
1.What exactly does Zkt guarantee, and what does it NOT?
2.Why are loads, stores, and conditional branches excluded from the Zkt list?
3.Can an out-of-order core claim Zkt while fusing, cracking, or eliding instruction sequences?