GMP API

[Torbjorn Granlund]

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

  This is what I understand, and why I made the question below. If the
  mpz_t functionality needs 3 man-years to be fixed, why you think using
  mpn would take less? Isn't mpz written over mpn?
  
Changning all of mpn to use error code for typically fatal allocation
problems rather than the current efficient method is the main daunting
task.  It will not be done, since I think it is the wrong approach.

  And to repeat my question, if that thin layer existed would you make it
  part of gmp?
  
It is not possible to answer such a question.  Contributions that are
good are considered for inclusion, while bad ones are heartlessly
rejected...

Many, many peiople have wrapped the mpn functions they need in their own
functionality.  This is what you ought to do too.
  
  >   > For crypto usages, it should not be very hard to use documented mpn
  >   > routines which do not allocate space.  Unfortunately, we don't currently
  >   > document O(n^2) multiplication or division functions, only more
  >   > primitive and more general functions.  For cryptographic applications,
  >   > O(n^2) mul and div/mod should be what one needs.
  >   
  >   I don't believe this is a solution. Using obscure or more low level
  >   functions, for crypto. A programmer should not need to deal with
  >   internal details, since it not only requires more work from him, but
  >   mainly it adds complexity to a code that should be simple (crypto code).
  >   Having safe code, shouldn't imply having more low level code.
  >   
  > I suppose I have the opposite view here.  Interfacing at a high level
  > brings in more code, 
  
  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.

  > 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?

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.

-- 
Torbjörn