random failures
Lots of examples of random numbers failing, leading to cryptographic failure.
The always classic Debian, OpenSSL, and the year of the zero.
The time Sony signed Playstation code with the same nonce and leaked the keys.
The Bitcoin app Blockchain used random.org for entropy. Bonus giggles for not following the HTTP redirect, but actually using “301 Moved Permanently” as a random number.
The paper Mining Your Ps and Qs has pretty extensive investigation into weak keys on network devices, many of which result from poor entropy.
libgcrypt lost entropy while mixing.
Now here’s a question. How many of these vulnerabilities could have been prevented by plugging in some sort of “true random” USB gizmo of the sort that regularly appears on kickstarter? I’m going to go with not many. USB gizmos don’t prevent inopportune calls to memset. USB gizmos don’t prevent nonce reuse. USB gizmos don’t block utterly retarded HTTP requests.
Would a USB gizmo have prevented a million Linksys routers from generating similar keys? Perhaps, but only if you thought to buy one and plug it into your router. And assuming the factory firmware has support for said gizmo. Does it? And even then, that still leaves 999,999 vulnerable routers. Maybe after market entropizers aren’t the best solution.
What about servers? Again, maybe but maybe not. I’ll pick on FreeBSD here. In 2008, it would take up to five minutes to properly seed random. In 2015, a similar bug prevented returning random data. Your gizmo can pipe a steady stream of red hot random bits into the entropy pool, but they won’t do much good if nobody reads them out.
Different OS, same bug. Android SecureRandom was not.
Oh, where was I going? It’s quite likely that your crypto will explode sooner or later, and it’s possible that random numbers will be implicated, but it’s very unlikely that some USB gizmo promising “true random” at kilobits per second will save you. Save your money instead.