nmav at gnutls.org
Tue Jun 22 22:35:00 CEST 2010
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?
More information about the gmp-devel