Interface of mpn_sec_ and mpn_cnd_ functions

[Torbjorn Granlund]

I think the mpn_sec_ and mpn_cnd_ functions should never allocate any
memory.  Instead, callers should pass all scratch areas to allow the use
of "secure" memory.

Or is this pointless?  The stack frames may get sensitive data, as
determined by the compiler used.  When we allocate (small) scratch
areas, we use the stack.  When a process is preempted the register
contents will get written to memory.

Assuming we decide to avoid explicit allocation, we need to work out
some interface details.

Let's take mpn_sec_mul as an example.  At least for now, it will just
invoke mpn_mul_basecase (either via a linker alias or through a call
indirection).  While it is mpn_mul_basecase, no scratch space is needed.
If we one day decide to support some sub-quadratic "sec" algorithm,
we'll need scratch space.

For future compatibility, we therefore would like to have an scratch
parameter now.  Then we need a mpn_sec_mul_itch function which tell how
much space is needed.  Its implementation will be simple now, returning
0.

Perhaps even O(n) functions like Niels' mpn_cnd_neg should have a
scratch parameter?  It seems safe to assume that these functions will
never ever need more than n limbs.

It will be somewhat awkward for users to call "itch" functions.  We
could simplify things by promising monotonousness in space requirements
in operand size, allowing init-time allocation passing some
known-largest operands to the itch functions.  For most functions such
monotonousness should be simple to define.  Division might be the one
exception, where the needs might not naturally increase monotonousness
in divisor size (but probably always in dividend size).

Torbjörn
Please encrypt, key id 0xC8601622