Problem with gmp_randinit_set

[Pedro Gimeno]

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...
Name: mt-copy-functions.diff
Type: plain/text
Size: 426 bytes
Desc: not available
URL: <https://gmplib.org/list-archives/gmp-bugs/attachments/20170215/f19eb581/attachment.bin>