[Development] CSPRNG vs DPRNG

[Edward Welbourne]

Thiago Macieira (11 October 2017 18:12)
> I've come to the conclusion that adding QRandomGenerator, a (mostly)
> cryptogrphically-secure PRNG, without adding a corresponding deterministic
> PRNG is a bad idea, especially with the changes that went in to the examples
> that changed all uses of qrand() to QRandomGenerator. We're telling people
> that they should not use QRandomGenerator for bulk data, but we are using it
> our examples without a good reason: qrand may be ugly, but it served the
> purpose well in the examples.

Valid concern.

> So I created a better option: QPseudoRandomGenerator (name bikeshedding later)

I should note that "pseudo-random" is in fact a variant on "chaotic", so
perhaps QChaoticGenerator would be more apt.   Chaos is not random,
it just looks a lot like it.

> on the flight home from QtCS. It's a simple wrapper around the Mersenne Twister
> provided by the Standard C++ Library, with the same API as QRandomGenerator
> that made the examples clearer. It can also be seeded to produce deterministic
> sequences and it does not have an entropy exhaustion problem.

Sounds like a good plan.

> But it has a hard requirement on std::mt19937 (see other email).
>
> Question:
>
> Do we add this class to 5.10 (feature freeze exception) or do we yank
> QRandomGenerator out from 5.10 and move it to 5.11?
>
> I've got it written and I've got the docs. I need to write the tests, but I
> can have it done by the weekend.

Thank you for promptness ;-)

> I'd prefer to do it now in 5.10 for the simple reason that the
> QRandomGenerator changes are already in and it's easier to change to
> QPseudoRandomGenerator than to go back to qrand and then do them again in 6
> months' time (with code churn).

+1 for freeze exception, while accepting revert as an acceptable alternative,

	Eddy.