[Development] Someone please fix the remaining qrand cases in SSL code

[Thiago Macieira]

On quarta-feira, 14 de junho de 2017 08:25:31 PDT Giuseppe D'Angelo wrote:
> Il 12/06/2017 22:45, Thiago Macieira ha scritto:
> > I can't submit changes to SSL-related code, so can someone apply the
> > equivalent ofhttps://codereview.qt-project.org/191738  to the files listed
> > in that commit's message?
> 
> There are a couple of problems arising from there:
> 
> 1) some place has a "TODO: use a CSPRNG". Given the current
> QRandomGenerator API, is there a way to know if a CSPRNG is actually
> being used or we're falling back to a plain PRNG?

It's not in the API, but in all non-misconfigured systems, it should be CSPRNG. 
You can misconfigure your system by running your Qt application in a chroot 
that doesn't have /dev/random or /dev/urandom.

There's also the issue of the system and CPU entropy pools. This could be an 
issue if the application uses QRandomGenerator in the first few hundred ms 
after boot. That can only affect device manufacturers and they should inspect 
their systems to know if that is happening. 

At least on Linux, once seeded, /dev/urandom does not stop working, so if we 
opened it (no bad chroot) and it has worked (system collected some entropy), 
the fallback should never kick in. Yes, that means the Mersenne Twister 
fallback is actually dead code on Linux. But this means that QRandomGenerator 
is good for unattended CSPRNG uses, such as networking code.

For key generation, I'd use /dev/random and require the user to move the 
mouse.

> 2) a test wants to generate a few MB of random data. Ideally this would
> be a no-brainer -- QRandomGenerator plus an engine from the standard
> library, but we can't use those engines yet (or can we?). So those
> places will need to keep qrand()?

#if QT_CONFIG(cxx11_random), after https://codereview.qt-project.org/196612 
integrates.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center