One concern may be the lack of a constant-time guarantee. If there are any optimizations that run differently depending on the numbers involved, then that may be an opening to a side-channel attack.

Upvoted, but such optimizations might exist for integer math, too. I’m not aware of any compiler that gives constant-time guarantees.

The best you can do is to write statements that you think map to certain instructions, and to check every release build to see what instructions the compiler chose.

You also may have to make sure that the buffers you use don’t cross page boundaries.

Unit tests that throw random numbers into the code and check execution time is always a constant number of clock cycles should catch nearly all timing side channels.

That won't work. When we say "constant-time code" what we really mean is "code whose running time is independent of its input". It won't really be constant due to factors like the OS scheduler and the initial state of the CPU's instruction cache.

What you really want is https://github.com/agl/ctgrind or something similar.

As dfranke said, it isn’t trivial to filter out the noise of having other code running in parallel to your code from that. Counting clock cycles, not wall clock time isn’t even enough as some attacks use wall clock time.

And it’s worse: that your code is constant-time in the absence of an adversary doesn’t guarantee that it is so in the presence of one. You will have to stress test your code with code running in other CPU threads that flush various caches, switch CPU modes, do DMA, etc.

Having said that, running with random inputs isn’t a bad idea, if only because you have to get confidence that the CPU manufacturer’s timing data is correct.

Big integer libraries are written to be as fast as possible, this pretty much guarantees the evaluation of primitive operations is not constant time.

Possibly, but I would assume it would would be too slow. While big does have assembly implementations, it is designed to handle very large numbers -- ~int128 sized numbers are probably too small for it to be efficient. I could be wrong though.

Correct. It is impossible for a generic signed/unsigned N-bit library to perform as efficiently as a specific uint128 code path.

I'm not sure but I suspect the algorithm contains optimizations that require direct access to the "limbs" of the big integers.

Or perhaps it's about avoiding allocations?