That is my own failure, of course. I wonder, though, whether everyone else knew about the VM RNG issue, or if only I had missed the memo. If the majority of poll respondents have never thought about the problem at all, perhaps I should start an awareness campaign on wikis and forums.

The poll, though, is unnecessary and I flagged it.

Meanwhile, you brought up:

Robert Brown's dieharder: http://www.phy.duke.edu/~rgb/General/dieharder.php

NIST Statistical Test Suite: http://csrc.nist.gov/groups/ST/toolkit/rng/index.html

Fourmilab's ENT: http://www.fourmilab.ch/random/

You noted that people could run these on their CSPRNGs to check randomness. No, they can't. These are all useful tools indeed; pentesters use them to check cookies and crypto tokens. But they can only tell you whether bits are correlated. It is very easy for an uncorrelated stream of bits to be terribly insecure: they simply have to be seeded from the same source.

It is not a good idea to suggest people test their RNGs with things like "ent". In "ent", Ruby's insecure rand() can appear competitive with /dev/random.

There's also the obvious confounding issue with testing an entropy pool by depleting it.

Case in point: The b0rked Debian OpenSSL RNG would certainly pass any statistical tests. But it still turned out to have only something on the order of 32767 unique sequences, i.e., 15 bits of entropy.

I suppose it would take a centralized web service to detect correlated unrandomness between servers. I am not personally willing to implement such a service right now.