_basecase or _sec? [
tg at gmplib.org
Thu May 2 13:59:12 CEST 2013
nisse at lysator.liu.se (Niels Möller) writes:
> If this is the reason, let's call them _sec.
Naming is difficult. But _sec is not appropriate for all basecase
functions. I think the idea of the currrent _sec suffix is to use it
only on functions that do *additional* work in order to get data
independent timing and memory access pattern, like powm_sec and the
recent div_sec routines.
Currently, mul_basecase and sqr_basecase presumably run in
data-independent time on all systems where basic arithmetic operations
run in data-independent time. (The latter is not always true, for
Also, mul_basecase and sqr_basecase are clean and simple with very
little overhead, and thus suitable for many applications which want
There two perspectives might call for different names.
But think it could make sense to use a non-leaky Karatsuba for a future
non-leaky mul and sqr. A prospective mpn_mul_sec function (and
mpn_mul_n_sec) seems to be a more abstract function than one that
sugggests a specific algorithm.
We should not underestimate the difficulty someone that want to use GMP
for crypto will face. They will find many functions that say nothing
about leakyness, and then suddenly some _sec functions. It seem natural
to ask "how to I add numbers without leaking?", "how do I multiply
numbers without leaking?", "how do I compute the gcd without leaking?".
We could certainly help by providing a parallel set of functions ending
in _sec. We could also document the leakyness of the current functions,
perhaps in a separate chapter on crypto use.
I think a starting point would be to list function that would be needed
in a _sec group, not worrying too much about naming at the same time.
We now have these:
function doc status
I think the division functions should be public, but following my
argument from a few lines above, they should not have the _sb part...
I see the need of the following:
More information about the gmp-devel