Problem with gmp_randinit_set

[Torbjörn Granlund]

Pedro Gimeno <gmpdiscuss at 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