Zkt Extension

Timing attacks are much more powerful than was realised before the 2010s, which has led to a significant mitigation effort in current cryptographic code-bases.

Cryptography developers use static and dynamic security testing tools to trace the handling of secret information and detect occasions where it influences a branch or is used for a table lookup.

Architectural testing for Zkt can be pragmatic and semi-formal; security by design against basic timing attacks can usually be achieved via conscious implementation (of relevant iterative multi-cycle instructions or instructions composed of micro-ops) in way that avoids data-dependent latency.

Laboratory testing may utilize statistical timing attack leakage analysis techniques such as those described in ISO/IEC 17825 cite:[IS16].

Binary executables should not contain secrets in the instruction encodings (Kerckhoffs’s principle), so instruction timing may leak information about immediates, ordering of input registers, etc. There may be an exception to this in systems where a binary loader modifies the executable for purposes of relocation — and it is desirable to keep the execution location (PC) secret. This is why instructions such as LUI, AUIPC, and ADDI are on the list.

The rules used by audit tools are relatively simple to understand. Very briefly; we call the plaintext, secret keys, expanded keys, nonces, and other such variables "secrets". A secret variable (arithmetically) modifying any other variable/register turns that into a secret too. If a secret ends up in address calculation affecting a load or store, that is a violation. If a secret affects a branch’s condition, that is also a violation. A secret variable location or register becomes a non-secret via specific zeroization/sanitisation or by being declared ciphertext (or otherwise no-longer-secret information). In essence, secrets can only "touch" instructions on the Zkt list while they are secrets.

HINT instruction forms (typically encodings with rd=x0) are excluded from the data-independent time requirement.

Floating point (F, D, Q, L extensions) are currently excluded from the constant-time requirement as they have very few applications in standardised cryptography. We may consider adding floating point add, sub, multiply as a constant time requirement for some floating point extension in case a specific algorithm (such as the PQC Signature algorithm Falcon) becomes critical.

Cryptographers typically assume division to be variable-time (while multiplication is constant time) and implement their Montgomery reduction routines with that assumption.

Zicsr, Zifencei are excluded.

Some instructions are on the list simply because we see no harm in including them in testing scope.

Thomas Pornin: "Why Constant-Time Crypto?" (A great introduction to timing assumptions.) https://www.bearssl.org/constanttime.html

Jean-Philippe Aumasson: "Guidelines for low-level cryptography software." (A list of recommendations.) https://github.com/veorq/cryptocoding

Peter Schwabe: "Timing Attacks and Countermeasures." (Lecture slides — nice references.) https://summerschool-croatia.cs.ru.nl/2016/slides/PeterSchwabe.pdf

Adam Langley: "ctgrind." (This is from 2010 but is still relevant.) https://www.imperialviolet.org/2010/04/01/ctgrind.html

Kris Kwiatkowski: "Constant-time code verification with Memory Sanitizer." https://www.amongbytes.com/post/20210709-testing-constant-time/

For early examples of timing attack vulnerabilities, see https://www.kb.cert.org/vuls/id/997481 and related academic papers.