I'm not sure it's quite as bad as rolling your own crypto. If you have a RNG you can run it through statistical tests, e.g. NIST's DIEHARD tests. If you know the physical principles on which your device works, I can't imagine a scenario where you'd be getting randomly-distributed bits that aren't actually random. And if you add those bits to your system's entropy pool, rather than using them directly, then it should be fine. That said, I agree that you still shouldn't use it in a production environment!
Your suggestion for e.g. the RPi RNG is problematic because (last I checked) there wasn't information online about how that actually works. For RNGs, I'd much prefer trusting my own design than a black box which could be outputting an AES-encoded string of all 0s for all I know!
I wonder though. There's a possibility that you'll screw something up and miss it during testing, but I've also seen some scary analyses of expensive off the shelf RNG hardware.
I'd say that if you're in a position of highly restricted capital that requires generation of tons and tons of secure random numbers, the ugly truth is that an open source DIY solution for generating your own entropy (especially if you can use multiple designs that are separately tested) might be safer than dumping your limited resources on proprietary unknowns.
I'm not totally sure as to which algorithms fit this definition but some suggestions might be DSA/ECDSA, Diffie-Hellman, SRP, etc.
The end result should almost certainly be at least as secure as the default entropy sources of keyboard timing, hard drive read/write latency, etc. If you're using a lot of random numbers, then /dev/urandom would become far more secure, and /dev/random would become far faster, since the entropy pool wouldn't drain as quickly.
Yes. However, running your own entropy generator looks ok to me (which is then fed to a random number generator)
Unless your entropy generator is only generating "nothing" this shouldn't be a problem beyond possible attacks to reading of the data
In this sense, rolling your own is a good start. It may not be a perfect implementation yet, this version may not even be secure but the fact that someone is making a start on an open source/open hardware version is commendable.
I hope this initiative pans out to something great!
Sure they do. I just read a paper how you could make a bias to this hwrng. I think it was even here on HN.
Designing a reliably fair and balanced RNG is not as easy a task as it may seem at first glance.
For those wanting a cheap HWRNG, a growing number of CPUs include them now. The SoC around which the rPi is based includes one that in my tests reliably pumps out 550+kbit/sec and passes the test I've thrown its output at - getting at it is easy so you just need a secure+reliable method for passing the bits to where you need them. Newer Intel chips also include a HWRNG, though I don't know if is as easy to expose (with the rPi just enable the relevant kernel module and read from /dev/hwrng).
[I did add notes on this to the "comparison of random number generators" page on Wikipedia but "User:Trinitresque" deemed the info not worthy and reverted the lot, I disagree of course but my day job and other commitments don't allow time for arguing the toss with Wikipedia editors!]