_basecase or _sec? [

[Torbjorn Granlund]

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
sure.)

Also, mul_basecase and sqr_basecase are clean and simple with very
little overhead, and thus suitable for many applications which want
minimal overhead.

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
  -------------------+------------
  mpn_sb_div_qr_sec     non-public
  mpn_sb_div_r_sec      non-public
  mpn_powm_sec          public

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:

  function
  --------
  mul
  gcdext
  add, sub

More?

-- 
Torbjörn