Running mpn_add_n at less than 1 cycle/limb

[Marc Glisse]

On Sun, 30 Aug 2026, Torbjörn Granlund wrote:

>  Do you mean that we should add mpn_sec_add_n and mpn_sec_sub_n?
>
> No, I think we should avoid having leaky mpn_add_n and mpn_sub_n.

Why though?
Applications that use GMP for crypto in a way where side-channel attacks 
make sense are probably a small minority of all GMP uses, so that 
penalizes all the others. And for the applications that care, 
mpn_sec_* sends a much clearer message about the guarantees provided by 
the function. In most cases, mpn_add_n and mpn_sec_add_n would just point 
to the same code, which should have minimal impact on the size of the 
library.

I don't care that much, I was just a bit surprised. If the speed 
difference is too small, maybe it isn't worth the trouble indeed.

-- 
Marc Glisse