> Since the number of times it would be able to flip the bit changes due to random fluctuations in time due to context switching of processes, this generates an arguably truly random bit (I would love to see a PoC that shows otherwise, however).<p>This wouldn't be true random. It's just using the time jitter introduced by context switching to introduce entropy. Similar to many other pRNGs that use system entropy, mouse movements, etc in order to seed the pRNG.<p>A pRNG is 'p' because if you know the conditions used, you can deterministically predict the outcome. The difficulty of recreating those conditions has nothing to do with being truly random.
'fuck, not again' - said the cryptographer. The title of the project is potentially very misleading.<p>I know most of you take this stuff seriously in your codes and rely on the well know cryptographically secure random number generators: <a href="https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator" rel="nofollow">https://en.wikipedia.org/wiki/Cryptographically_secure_pseud...</a>
It seems a bit ambitious to call this true random without any analysis of randomness quality or predictability.<p>I find it very unlikely this will be shown to be better than existing RNG solutions.<p>It's clever, but clever in the way that sleep sort is clever, at least until proven to be of actual benefit.
This looks to be the same technique as Dan Kaminsky's DakaRand, including the debiasing: <a href="https://dankaminsky.com/2012/08/15/dakarand/" rel="nofollow">https://dankaminsky.com/2012/08/15/dakarand/</a><p>See also Kaminsky's implementation of the same approach in pure JS: <a href="https://gist.github.com/PaulCapestany/6148566" rel="nofollow">https://gist.github.com/PaulCapestany/6148566</a><p>and Ryan Finnie's implementation in Perl: <a href="http://www.finnie.org/2012/08/14/twuewand-2-0-released/" rel="nofollow">http://www.finnie.org/2012/08/14/twuewand-2-0-released/</a><p>The big concern I have is how reliable this is on virtual machines. Just about all physical machines I'd want to use have high-quality, trustworthy-within-my-threat-model (i.e., "if the NSA wanted to attack my silicon, there's easier silicon for them to attack") hardware random number generators, and all physical machines I'd want to use pick up sufficient randomness from the kernel's entropy magic thing. But virtual machines often don't have access to the hardware RNG, and they don't have access to enough other hardware to populate entropy. It seems like this technique would be particularly risky there ... although I don't think anyone's published an attack on DakaRand yet, so maybe it's fine!
I'm really hesitant to even consider this without it being run through the Diehard Tests[0], since from my understanding, "True Randomness" should be cryptographically secure should this be used in a CSPRNG.<p>[0]: <a href="https://en.wikipedia.org/wiki/Diehard_tests" rel="nofollow">https://en.wikipedia.org/wiki/Diehard_tests</a>
This is almost certainly not more random than this: <a href="http://www.fourmilab.ch/hotbits/" rel="nofollow">http://www.fourmilab.ch/hotbits/</a><p>It is a cool idea.
The debiasing idea is due to von Neumann himself:<p><a href="https://en.wikipedia.org/wiki/Fair_coin" rel="nofollow">https://en.wikipedia.org/wiki/Fair_coin</a>
What if get_bit happens to be deterministic on a particular machine? Then get_fair_bit would be stuck in an infinite loop. This can potentially happen when CPU is so overloaded that executing the bit-flipping instruction takes longer than a millisecond.
Wouldn't an example of a truly random number generator be to open up a pseudo random webpage (say something like www.engadget.com/page/<pseudo_random_number>) and do a modulo count of the number of whitespace separated words/tokens?
This post reminded me of this other project: <a href="https://github.com/dasmithii/RCRand" rel="nofollow">https://github.com/dasmithii/RCRand</a> (a similarly silly but fun race condition based RNG)
this is <i>not</i> random.... it is deterministic.<p>typical round-robin times are on the order of 10ms, so you would have a significant amount of non-context-switched 'random' numbers, which when combined with analysis using the cycle counter.... namely a counter running at the clock-speed of your processor would yield a <i>very</i> non-random value.
Ego has infected this thread. We can't just say that this project is interesting. We have to talk about "expensive" computation. Why? What does "ambition" have to do with computer science?