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 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel