Pedro Gimeno <gmpdisc...@formauri.es> writes: Ah, yes, that was a problem that needed to be avoided. Thanks for looking into this. One possible fix would be to resurrect my patch for a different seeding routine, which was based on the xxtea encryption algorithm. That one is faster and uses far less mpz code, and I think it wouldn't be difficult to get rid of mpz usage totally. It was written in or before 2006, I believe, and I rebased it in 2009, so merging it with current code might be troublesome. Fortunately, that part of the code doesn't seem to have changed a lot. The problem is that it wouldn't be a good idea to apply that patch to stable versions, because it causes the sequences to be different. I've attached the patch as it was in 2009 (against revision af3f365253c5). 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.
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? -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs