1
votes

Take fast PRNG like xoroshiro or xorshift and 'true' entropy based generator like /dev/random.

Seed PRNG with 'true' random, but also get a single number from 'true' random and use it to XOR all results from PRNG to produce final output.

Then, replace this number once a while (e.g. after 10000 random numbers are generated).

Perhaps this is naive, but I would hope this should improve some aspects of PRNG like period size with negligible impact on speed. What am I getting wrong?

What I am concerned about here is generating UUIDs (fast), which are basically 128-bit numbers which should be "really unique". What my concern is that using modern PRGN like xorshift family with periods close to 'just' 2^128 the chance of collision of entropy seeded PRNG generator is not as negligible as it would be with truly random numbers.

1
Some context added...Mirek Fidler
The XOR part reminds me of security through obscurity (it's more obscure than just, say, reseeding the PRNG once in a while, and may not increase entropy beyond that). That said, I can't conclusively say what effect it actually has on entropy (either XOR or reseeding).Bernhard Barker
Please let me restate that the problem at hand is not about security. The issue is really about probability that two 128-bit results are the same.Mirek Fidler
Even thought you're not primarily interested in the cryptographical aspect, you may want to try crypto.stackexchange.com or security.stackexchange.com ; I assume the users there know all about PRNG periods.m69 ''snarky and unwelcoming''

1 Answers

1
votes

The improvements are only minor compared to the plain PRNG. For example the single true random number used for masking the result can be eliminated by taking the XOR of successive results. This will be the same value as the XOR of successive plain PRNG numbers. So if you can predict the PRNG, it is not too hard to do the same to the improved sequence.