Problem with gmp_randinit_set
gmpdiscuss at formauri.es
Wed Feb 15 05:05:41 UTC 2017
Torbjörn Granlund wrote, On 2017-02-15 03:40:
> Pedro Gimeno <gmpdiscuss at formauri.es> writes:
> One possible fix would be to resurrect my patch for a different
> seeding routine, which was based on the xxtea encryption
> I like the idea of applying a symmetric cipher for PRNG; I have in fact
> done some work towards using AES for that in GMP. I don't know about
> xxtea or its pros and cons, and perhaps that is superior to AES. On
> AES's plus side is that we can access hardware instructions in many
> cases, and that a C implementation is quite small.
I chose xxtea for being simple and small (as can be seen in the patch) and for having variable block size, so I could encrypt just 1 block of 19936 bits, eliminating the need to choose a suitable enciphering mode. For ciphers with smaller block size, ECB, OFB, CFB and CTR are definitely discarded; CBC and PCBC could perhaps work (I'm using names from https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation ). I tested xxtea's randomness properties and I was very satisfied with the results.
As a temporary fix, it would also work if minigmp's modular exponentiation could be used, to make the output compatible.
> But I don't think we can leave MT broken or replace it (e.g.,
> gmp_randinit_mt should use Mersenne Twister, period). Shouldn't it be
> possible to get both a and b (of the reporter's code) in the precis same
> state after assigning one to the other, without significant dependency
> changes in the MT code?
With something like the attached? Perhaps. In fact I don't know why it isn't doing it now. Can that structure possibly come from disk or some other place that makes the pointers invalid? I guess not.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 426 bytes
Desc: not available
More information about the gmp-bugs