It is not well-documented, but it turns out that if you try to run crypto benchmark code on a STM32F407 ("discovery") board (with an ARM Cortex M4 CPU) with instructions in SRAM (instead of Flash), then you get extra delays, unless you set SYSCFG_MEMRMP accordingly. After a week-end of dabbling, I can now run my benchmarks (for Falcon/FN-DSA) at 168 MHz with no wait states or cache issues. Details here: https://github.com/pornin/c-fn-dsa/tree/main/bench_cm4

(As a side-note, I have done some more assembly optimization work, so signing cost is now 19.7 mcycles at n=512, down from 22.0 previously.)

New paper: https://eprint.iacr.org/2025/435
To some extent, it’s a blog post in scientific article format. In that text I argue that writing constant-time code has become mostly infeasible in general (because there are JIT compilers everywhere, especially where you cannot look, and they’ve become smart).

It’s still worthwhile to write code in a “constant-time” way, but you’ll get the real thing only by adjusting things for your specific hardware.

On a whim, I did something which is arguably a bad idea: a pure JavaScript implementation of FN-DSA (Falcon). It's there:
https://github.com/pornin/js-fn-dsa

Key pair generation, and to a lesser degree signature generation, are not constant-time (not that making constant-time code is really feasible in JavaScript). The JavaScript story of handling secret keys is terrible anyway. The signature verification code, though, should be fine.

It all fits in a single 2530-line comment-heavy source file, with no external dependencies; it's not that big! I have cursorily tested it in Chrome, Safari (on iOS) and Firefox. Presumably it should also run on Edge and Node.js, but I have not tried.

Falcon on the ARM Cortex-M4: it got about twice faster.
https://eprint.iacr.org/2025/123

Compared with optimized Dilithium (ML-DSA) on the same hardware, signing is "only" 5.4 times slower, but verifying is 4 to 6 times faster (and uses a lot less RAM as well). Falcon/FN-DSA might be deemed usable even on such microcontrollers.

(Among things, I use a combined addition/subtraction routine, when computing x+y and x-y for two floating-point values x and y. I think I saw that somewhere before but I don't remember where; it's a nice trick and it should be credited properly, so if anybody has a pointer that would be helpful.)

Following up on my Rust implementation of "prospective FN-DSA" (i.e. Falcon + support for pre-hashing as in ML-DSA), I made C and Go versions, with the same features, and full reproducibility across all three implementations:
https://github.com/pornin/rust-fn-dsa
https://github.com/pornin/c-fn-dsa
https://github.com/pornin/go-fn-dsa

Everything ought to be correct, fast (as can be made so, but I am not unhappy with the performance), and constant-time (again within what can be ensured in a world where compilers and hidden JIT compilers are smart enough to recognize disguised Booleans).

I made a Rust implementation of FN-DSA/Falcon. Of course it is not (yet) the "real" FN-DSA since NIST has not published any draft standard yet; I will align the implementation with the drafts as they go live.
https://github.com/pornin/rust-fn-dsa
https://crates.io/crates/fn-dsa

It's as fast as the C code (faster for verification, actually, thanks to some more AVX2). It's portable and presumed secure (best effort on constant-time, no guarantee though, recent LLVMs are good at recognizing disguised Booleans and inserting back conditional jumps). My _ambition_ is that this becomes the "canonical" FN-DSA implementation in the Rust ecosystem.