Torbjörn Granlund wrote, On 2017-02-15 03:40: > Pedro Gimeno <gmpdisc...@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.
mt-copy-functions.diff
Description: plain/text
_______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
