AtomicRNG: Feeding The Linux RNG With Java & Alpha Ray Visualizer

[phoronix]

Phoronix: AtomicRNG: Feeding The Linux RNG With Java & Alpha Ray Visualizer

AtomicRNG is an open-source project started by a Phoronix reader that's an experimental random number generator that feeds the Linux entropy pool and is based on an Alpha Radiation Visualizer...

http://www.phoronix.com/scan.php?page=news_item&px=AtomicRNG-Linux-Random-RNG

[opensource]

But isn't this still a software based pseudo random number generator?
How about this: https://www.kickstarter.com/projects...ropy-generator

[Drago]

But isn't this still a software based pseudo random number generator?
How about this: https://www.kickstarter.com/projects...ropy-generator

The software gets its seed by truly random nuclei decay events.

[opensource]

The software gets its seed by truly random nuclei decay events.

Then it's not pseudo random I guess, good.

Found this vid https://www.youtube.com/watch?v=UCH-_6PeCl4. Same technique is used to measured radiation with smartphones, only here it is not the amount of pixels so much but the (random) position.

[opensource]

The administrator has specified that you can only edit messages for 5 minutes after you have posted. This limit has expired, so you must contact the administrator to make alterations on your message.

5min is realy bad.

Although an alpha emitter Am-241 source is used (emits 60keV gammas too), beta and/or gamma emitting sources could may be used too.

[curaga]

The software gets its seed by truly random nuclei decay events.

Except nuclear decay is not truly random, it can be influenced by people's will. True story, they rigorously measured that at the Burning Man festival.

[mctylr]

But isn't this still a software based pseudo random number generator?

It takes a sample from a physical phenomenon that is unpredictably random (the time / position of the alpha partials emitted from the Americium 241 found in a common smoke detector, as captured by a webcam), and feeds that into the xxHash as a key whitening / key-strengthening which feeds it into the standard Java pseudo-random number generator (PRNG). The java.util.Random is a simple linear congruential generator (LCG), while the SecureRandom which is suppose to be a cryptographically strong pseudo random number generator.

Given that xxHash describes itself as "extremely fast non-cryptographic Hash algorithm" this clearly suggest it is not suitable for usage as part of a secure random number generator.

While it appears to be a fun exercise, the ad-hoc (seemingly random) nature of cobbling pieces together suggest it was an educational project for Thomas "V10lator" Rohloff, but I don't think that it is in any way actually secure or to be trusted. And is lacking compared to the other open hardware RNG methods already tried.

In fact the project reminds me of two anecdotes, the first from Bruce Schneier, which is so commonly cited that it has been called Schneier's Law, the second is from Donald Knuth on his own experience of trying to create an (P)RNG, Algorithm K, early (1959) in his career, and is an excerpt from The Art of Computer Programming Volume 2: Seminumerical Algorithms, 3rd Edition.

[opensource]

Given that xxHash describes itself as "extremely fast non-cryptographic Hash algorithm" this clearly suggest it is not suitable for usage as part of a secure random number generator.

Given the Am-241 area bigger than the sensor size, so that at least the emitter source is evenly spread, it is interesting to think, that this is still not random enough. Where could the non-randomness come from?

[V10lator]

Hey guys, developer here.

Found this vid https://www.youtube.com/watch?v=UCH-_6PeCl4. Same technique is used to measured radiation with smartphones, only here it is not the amount of pixels so much but the (random) position.

I'm experimenting with ray-tracing to trace the real impact point of the alpha ray. The result gives way less numbers but is more in line with your example (except that it also tries to calculate the energy carried by the alpha ray):

Codes are at a seperate branch.

Although an alpha emitter Am-241 source is used (emits 60keV gammas too), beta and/or gamma emitting sources could may be used too.

That's right, but you would need better shielding. I really wouldn't recommend using anything other than alpha radiation sources.

which feeds it into the standard Java pseudo-random number generator (PRNG).

Each hash has a 5% chance to re-seed the Java PRNG (and as a result break the cicle of predictable numbers, which also never get feeded to /dev/random, except when mixed up with true random numbers), else it gets feeded to /dev/random.

Given that xxHash describes itself as "extremely fast non-cryptographic Hash algorithm" this clearly suggest it is not suitable for usage as part of a secure random number generator.

What makes you think that? The high number of collisions? That's why it's a "xxHash based algorithm": First it uses lz4s xxHash implementation which salts (the salt is taken from the Java PRNG) the hash, second it hashes the number 2 times (with different salts) and randomly mixes up the results.

While it appears to be a fun exercise, the ad-hoc (seemingly random) nature of cobbling pieces together suggest it was an educational project for Thomas "V10lator" Rohloff

Yes, it is a educational project. Also it's under heavy development, that's why you should only use builds marked as Release on the Jenkins page. Else weird things might happen. None the less I hope to transform it into a secure RNG running as a kernel module. This ultimate goal will need time and most likely more developers.

but I don't think that it is in any way actually secure or to be trusted.

I'm lacking experience with RNGs/cryptography. Again a point why this most likely needs more developers.

And is lacking compared to the other open hardware RNG methods already tried.

Thanks for the links, I'm a bit busy atm but will have a look at them soon.



If anyone heree is more experienced with this than me: I would love to talk to you about the pros and cons of some techniques.

[opensource]

Hi TAXI,
as posted in my prior reply, I don't see why the random position on the sensor shouldn't be random enough, but I'm not a pro in this field.