Manifest for RISC-V Constant Time Floating-Point Operations

What are you optimizing for?

SubscribeSign in

Manifest for RISC-V Constant Time Floating-Point Operations<br>When constant time integer operations are not enough!

FPRox<br>Jun 20, 2026

Share

Disclaimer: this post summarizes a proposal that spawned out of multiple discussions in RISC-V PQC Task Group and FP SIG. The post itself represents my own suggestions and has not been endorsed by any of those groups; all mistakes are my own.<br>In this blog post, we survey the need for floating-point operations exhibiting Data Independent Execution Latency (DIEL) and we introduce a RISC-V extension proposal to address this need. DIEL is more flexible (and more esoteric) than the clickbaity “Constant Time” title :-). At the end of this post you will find a small appendix section covering the differences between DIEL and constant time.<br>Implementation timing that is dependent on the data can be used as a side channel to uncover the data, include private assets such as cryptographic keys. This was exposed by Paul Kocher on its seminal 1996 paper Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems [Kocher 1996 ].<br>DIEL implementations are a good way to protect against such timing attacks.<br>RISC-V has specified DIEL scalar integer operations, in the form of the Zkt extension, Zkt was defined alongside the original scalar crypto extensions. This was extended to DIEL vector operations, the Zvkt extension, specified alongside the vector crypto extensions. None of those extensions covered floating-point operations.

Subscribe

Floating-Point Latency Considered Harmful

Floating-Point computations have been known to be difficult to handle securely in cryptographic context. The paper On Subnormal Floating Point and Abnormal Timing [Andrysco 2015] demonstrated that even in carefully crafted contexts it was possible to exploit micro-architectural differences in the latency difference exhibited by the execution of a single floating-point operation on different input values to expose secrets and break security assumptions. This has lead to abandoning use of hardware floating-point for security primitives and even either abandoning floating-point completely or relying on integer based emulations libraries [Andrysco 2018] .<br>There is an ongoing effort to specify a post-quantum cryptography (PQC) algorithm called FALCON (NIST FIPS 206 draft). FALCON may make use of floating-point operations, including on critical private assets.<br>In such a case, for an implementation not to expose those assets, it is necessary that those floating-point operations be implemented in a DIEL fashion.<br>This use case justifies the study of DIEL floating-point, but I believe we could untie the two: if cryptographers discard the use of floating-point operations because they believe most implementation to be unsafe, we could solve the chicken and egg problem by demonstrating that “constant-time” floating-point is feasible and could be easily specified and implemented.<br>Proposal for DIEL Floating-Point Extensions

RVIA, in particular the PQC Task Group (PQC TG) and the Floating-Point Special Interest Group (FP SIG) have started discussion around what DIEL floating-point would look like for RISC-V. The discussions were originally spawned by the possibility that NIST FN-DSA specification might use floating-point operation. After studying the question, I believe this initial reason is not actually necessary to spawn this effort as timing properties/limitations of floating-point operations have been considered in many different contexts [Dooley 2006 ], [Andrysco 2015] , [Andrysco 2018] .<br>Challenges and Open Questions

The questions are:<br>What operations should be covered?

Which Operand(s) should be covered in each covered operations?

How should they be grouped?

Floating-point instruction can be implemented in a many different ways (e.g. iterative versus pipelined datapath) exposing a large range of tradeoffs. Different implementations may have made different choices when it comes to data dependent latency optimizations which may make enforcing DIEL on Floating-Point operations more or less difficult.<br>The state of the art standard practices (e.g. fully pipelined FMA operator) and the generalization of at-speed support for subnormal inputs/results should simplify the specification of DIEL FP operation mandates.<br>Scalar and Vector could be covered separately: for example with a Zfkt (scalar) extension and a Zvfkt (vector) extension, such that implementers (and profile builders) can select which subset makes the most sense in each context. Platform without vector support could still implement cryptographic algorithms relying on floating-point operations securely; and platform with vector could decide to limit the DIEL floating-point to the scalar side (although this does not seem like an ideal choice). This division also mirrors what was done for non-floating-point operation with Zkt and...