3 ms·

worth mentioning (that sort of main premise of the article that gets a little bit unnoticed in all the methodology discussion): all existing HWRNG are relativel

worth mentioning (that sort of main premise of the article that gets a little bit unnoticed in all the methodology discussion): all existing HWRNG are relatively low bandwidth - because they are bound by physical process, rather then endless spinning up of /dev/urandom. They all have to wait for physics to produce each bit, and existing chips don't have that much "physics" in them. 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.

atoponce 9y ago
> all existing HWRNG are relatively low bandwidth 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-random-number-generator-drng-software-implementation-guide https://software.intel.com/en-us/articles/intel-digital-rand... 2. https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators https://en.wikipedia.org/wiki/Comparison_of_hardware_random_...
- lordmax 9y ago
  Here is the problem: most of these stats are not what they pretend to be (unless exact circuit / spec is published). Look at low level details of building say avalanche noise source: http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/ - bandwidth is mostly bound by voltage/frequency/sampling resolution - how often you can trigger entropy event and how many of them in parallel? True result for one AN circuit: 2000 bits/sec. 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.
- lordmax 9y ago
  btw I have RPI3 too, thanks for mentioning. it would be fun project to figure out can we reach true source on that chip. but 1,5Mpbs? highly suspect. they don't have space nor clock speed to sample so many true events on that tiny chip. need to dig into the Broadcom spec to find out more!

atoponce 9y ago

> all existing HWRNG are relatively low bandwidth 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-random-number-generator-drng-software-implementation-guide https://software.intel.com/en-us/articles/intel-digital-rand... 2. https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators https://en.wikipedia.org/wiki/Comparison_of_hardware_random_...

lordmax 9y ago
Here is the problem: most of these stats are not what they pretend to be (unless exact circuit / spec is published). Look at low level details of building say avalanche noise source: http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/ - bandwidth is mostly bound by voltage/frequency/sampling resolution - how often you can trigger entropy event and how many of them in parallel? True result for one AN circuit: 2000 bits/sec. 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.
lordmax 9y ago
btw I have RPI3 too, thanks for mentioning. it would be fun project to figure out can we reach true source on that chip. but 1,5Mpbs? highly suspect. they don't have space nor clock speed to sample so many true events on that tiny chip. need to dig into the Broadcom spec to find out more!