Problem with gmp_randinit_set
tg at gmplib.org
Wed Feb 15 02:40:15 UTC 2017
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
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?
Please encrypt, key id 0xC8601622
More information about the gmp-bugs