4 ms·

It seems a bit ambitious to call this true random without any analysis of randomness quality or predictability. I find it very unlikely this will be shown to b

It seems a bit ambitious to call this true random without any analysis of randomness quality or predictability. I find it very unlikely this will be shown to be better than existing RNG solutions. It's clever, but clever in the way that sleep sort is clever, at least until proven to be of actual benefit.

kazinator 10y ago
It's expensive; it spins for a millisecond to obtain one bit. Suppose this is running on a quiescent system with no interrupts or other tasks running. I can see it degenerating into deterministic behavior. Suppose the RTC counter and the CPU clock are from the same master clock, and the code is executing cleanly to the clock from on-chip caches. Ultimately, the question is: is there really one bit of entropy from each call to get_bit(), and under what conditions?
- dragontamer 10y ago
  It spins for a millisecond to have a chance of obtaining half a bit actually. It takes two clock calls to create a chance of getting a bit, and only if the bit pattern changed during that period.
  - infogulch 10y ago
    It can create a whole bit per spin, but my guess is that the output was predictable enough for the author to notice, so they added a single round of the most basic random scrubber. 'Hey it looks random now, ship it!'
    - dragontamer 10y ago
      From that perspective, I think we can use the methodology in this code as an input into SHA3 / Keccak or Skein (A SHA3 finalist). I dunno Keccak, so I'll talk from a Skein perspective. If every millisecond you added the "nanoseconds" field with the Skein cryptofunction salt = mix(nanoseconds + salt + current seed + other Skein stuff), it'd be pretty darn random. (Apparently Keccak can 'sponge up' entropy somehow, but I don't know the mechanism that it does it with) The output would at least be a crypto-secure PRNG. All that needs to be proven after that fact is whether or not enough entropy was being gathered from the real time clock.
mindslight 10y ago
Analysis of the output can only disprove randomness. For example, not knowing the key it is impossible to condemn the deterministic output of AES-CTR (assuming the properties of AES hold). The author really needs to cut back the grandiose claims. Projects like this are more part of the learning process, than something useful to others.

kazinator 10y ago

It's expensive; it spins for a millisecond to obtain one bit. Suppose this is running on a quiescent system with no interrupts or other tasks running. I can see it degenerating into deterministic behavior. Suppose the RTC counter and the CPU clock are from the same master clock, and the code is executing cleanly to the clock from on-chip caches. Ultimately, the question is: is there really one bit of entropy from each call to get_bit(), and under what conditions?

dragontamer 10y ago
It spins for a millisecond to have a chance of obtaining half a bit actually. It takes two clock calls to create a chance of getting a bit, and only if the bit pattern changed during that period.
- infogulch 10y ago
  It can create a whole bit per spin, but my guess is that the output was predictable enough for the author to notice, so they added a single round of the most basic random scrubber. 'Hey it looks random now, ship it!'
  - dragontamer 10y ago
    From that perspective, I think we can use the methodology in this code as an input into SHA3 / Keccak or Skein (A SHA3 finalist). I dunno Keccak, so I'll talk from a Skein perspective. If every millisecond you added the "nanoseconds" field with the Skein cryptofunction salt = mix(nanoseconds + salt + current seed + other Skein stuff), it'd be pretty darn random. (Apparently Keccak can 'sponge up' entropy somehow, but I don't know the mechanism that it does it with) The output would at least be a crypto-secure PRNG. All that needs to be proven after that fact is whether or not enough entropy was being gathered from the real time clock.

mindslight 10y ago

Analysis of the output can only disprove randomness. For example, not knowing the key it is impossible to condemn the deterministic output of AES-CTR (assuming the properties of AES hold). The author really needs to cut back the grandiose claims. Projects like this are more part of the learning process, than something useful to others.