GMP API

[Nikos Mavrogiannopoulos]

Torbjorn Granlund wrote:

>   More code to a single place, which is good.
>   
> I think the hacker world is suffering from a "libraritis", where we
> bring in libraries that use libraries that use libraries.  The actually
> used code is impossible to overview, so are the security consequences.
> I think one should resist the temptation to interface at a too high
> level for a little short term convenience.

This is not the case here. The case is that we have a crypto library
using libgmp and libgcrypt using its own version of libgmp. I see merit
on the reasons libgcrypt replicated the code, and I though it would be
good idea to have this in main libgmp so all users can benefit.

>   > interfacing just to mpn_add_n, mpn_sub_n,
>   > mpn_addmul_1, mpn_mul_1 and a few more, would me feel much more
>   > confident about the crypto code.  Also, there is a lot of speed gain
>   > from using low-level functions for the small operand one uses in crypto.
>   
>   I don't see why someone who is implementing crypto should do more work
>   than someone who isn't. And it is not about crypto, but rather about
>   applications that need error recovery from out of memory.
>   
> Error recovery for out-of-memory is possible with GMP today.     Why do
> you imply that is not possible?

How a program could recover in the example I gave with the mpz_mul()?

> Crypto is special in several ways:
> 1. Few, specific operations are used.
> 2. Operands are small, making trivial O(n^2) algorithms suitable.
> 3. It is beneficial to depend on a small amount of externally maintained
>    code, for auditing reasons.

So your suggestion is to avoid gmp for crypto?

regards,
Nikos