The main novelty factor of "camera noise HRNG" is that we effectively leveraging 12M micro HRNGs in parallel - thats where that firehose of entropy is coming from.
The main novelty factor of "camera noise HRNG" is that we effectively leveraging 12M micro HRNGs in parallel - thats where that firehose of entropy is coming from.
The Intel on-die DRNG generator has a cited bandwidth of about 3 Gbps [1]. On my Raspberry Pi 3, it has an on-die generator via BCM-2835. Single threaded testing with dd(1) shows about 1.5 Mbps bandwidth.
Off-chip, using $25 RTL-SDR dongles, you can get about 2.8 Mbps of bandwidth. In fact, if you look at the Wikipedia article comparing HWRNGs [2], you can see that there are a lot of implementations with suprisingly high bandwidth. Some you'll empty your wallet with, others not so much.
The point is, there are plenty of HWRNGs out there with high bandwidth. Whether or not you trust them though, is a completely different matter.
1. https://software.intel.com/en-us/articles/intel-digital-rand...
2. https://en.wikipedia.org/wiki/Comparison_of_hardware_random_...
What a lot of these vendors do is have some physical phenomena on the chip that feeds hardware "whitener" (endless hashing) that responds without blocking to all requests. That's practically hardware version of “/dev/urandom" that is bound only by chip IO - but its completely disconnected from bandwidth of actual “true” entropy phenomena underneath. of course it is still good CSRNG, but its not “true” source. btw nice exception: TrueRNG team are pretty honest providing direct schema - hence the real entropy speed of 40kb/sec.
In short every single entry on that list should be independent inspected down to specs and schema of whitener. If they are not publishing chip spec with exact details I highly highly doubt the bandwidth of “true” entropy events are really approaching GBps - this is the speed of whitener, not of actual generator.