[Development] CSPRNG vs DPRNG

Thiago Macieira thiago.macieira at intel.com
Wed Oct 11 18:12:55 CEST 2017


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.

And since we're using it in our examples, people will start using it 
indiscriminately because they don't have a better option.

So I created a better option: QPseudoRandomGenerator (name bikeshedding later) 
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.

But it has a hard requirement on std::mt19937 (see other email).


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.

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).
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list