[PATCH] Custom random number generation function.

[Pedro Gimeno]

Niels Möller wrote:
> Pedro Gimeno <gmpdevel at formauri.es> writes:
> 
>> Exposing the full struct is a possibility, but such struct should
>> preferably be kept opaque and only expose an interface to set the
>> functions it contains. Example:
>>
>> void
>> gmp_randinit_generic (gmp_randstate_t    rstate,
>>                       gmp_randseed_fn_t  randseed_fn,
>>                       gmp_randget_fn_t   randget_fn,
>>                       gmp_randclear_fn_t randclear_fn,
>>                       gmp_randiset_fn_t  randiset_fn);
> 
> What's the use case for this? To me, if you have a custom generator, e.g.,
> one with decent cryptographic properties, and want to use it with gmp,
> it makes no sense to me at all to have gmp know about seeding the
> generator or save and restore its insternal state.

Good cryptographic properties are not the only reason to change the
generator. There have been instances of Monte Carlo algorithms giving
wrong results due to bias in the PRNG they used (bias is often
application-specific, in the sense that certain statistical properties
have more importance than others for certain uses). Mersenne Twister in
particular is not a generator I trust much, and I don't mean it in the
cryptographic sense.

The immediate use case that comes to my mind is an interpreter using GMP
that has a choice among several possible RNGs. As for saving and
restoring, resumability (i.e. the ability to save the current progress
and resume later at the same point) and reproducability (transfer of the
state to different people who can then test the results from that point
on) are good reasons IMO.

> It's the application's job to seed and maintain the generator, and gmp
> should just use it when generating various random numbers. A typical
> interface of a cryptographic randomness source is something like this
> (from the Nettle library):
> 
>   typedef void (nettle_random_func)(void *ctx,
> 				    unsigned length, uint8_t *dst);

That's basically the same interface of the randget_fn function. It would
certainly be easy to just ignore gmp_randseed and use an user-provided
seeding function. The same goes for each of the other functions. But for
those reasons, it would make no sense at all to provide custom RNG
support. The only reason is uniformity and ease to use: use always
gmp_randseed to seed, gmp_randclear to clear, gmp_randinit_set to
initialize with a given value, gmp_urrandomm to obtain a number, and so
on, regardless of the algorithm.

-- Pedro Gimeno