State of PRNG code in GMP

Torbjörn Granlund tg at
Wed Jun 3 13:15:21 UTC 2020

nisse at (Niels Möller) writes:

  > /* PRNG algorithm specific data for any constants, buffered random bits, or
  >    other state.  The _mp_data field should typically point to a algorithm
  >    specific struct.  The _mp_datasize field is used by generic code for
  >    de-allocating and copying a gmp_prng_t in an algorithm agnostic manner.  */
  > struct appdata {
  >   void* _mp_data;
  >   size_t _mp_datasize;
  > };

  Does generic code really need to copy the algorithm specific data?

It seems nicer to have generic code do as much as possible.  And it
saves having pointers in the struct for copy and cleanup functions.

Do you see any disadvantage?

  > /* Generic PRNG init function.  Is this really a good idea?  A problem is that
  >    this will pull in all PRNG code into a binary which uses just one
  >    algorithms.  It even pulls in mpz functions in a mpn-only program if any
  >    PRNG uses mpz. */

  I'd prefer to not have it. I think it's rare to initialize with an
  algorithm enum selected at run time.

I agree.

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list