I’m looking to make v2.0 of my random number generator based off of Uranium-238 decay.
My first generation relied on labview and other proprietary software. I’d like to remake the entire system with only FOSS components.
Previous version (and likely the new version) uses the entire surface area of an image sensor so rather than a single “particle detected” output, it uses the coordinates of pixels struck (which will be quite a few) during the refresh rate to form a high speed output stream.
Cheers,
-Jim
Americium is primarily an Alpha emitter; this would work, but pose some challenges, primarily that you cannot keep the source 100% sealed. Uranium metal, for example, includes a fair amount of Beta emissions in its decay chain, and thus can be kept in a thin film sealed which makes handling safer. However, the Americium in a smoke detector is often sandwiched between two metal foils but the design of the chambers can vary.
It’s something that could be a design decision or a maker decision for the individual build, depending on how things work in practice. It’s been ages since I’ve built a new one of these number generators, so the sensors responsiveness to ionizing radiation could have changed as well. If Alpha still has a good response on easy to acquire sensors with decent refresh rate and F/OSS support then I’m all for it.
Cheers,
-Jim
Sounds like Schrödinger’s cat is flipping the coin.
1 Like
Are you looking for a pure RNG or a Cryptographically Secure RNG suffce?
#trustthemath
Bruce icon
1 Like
So here’s the tricky thing to that answer: whilst the Kernel’s /dev/urandom and /dev/random*** suffice for most tasks, when Containers and VMs start to come into the equation the host machine doesn’t always have a high enough entropy pool for safe operation. One or two VMs? Not a big deal. Deploying a hundreds of containers per host, or services that heavily rely on keygen? Things become a bit more complicated.
So It’s a true RNG, but a very fast true rng compared to most solutions. It’s output is safe enough to use as-is, or use it to seed the host’s entropy pool. Can still use /dev/urandom, but it’s Unblocking mode will be safer when there is enough entropy to not re-use bits from the pool. The man page also notes a still undisclosed attack on urandom, and to use /dev/random when the operation is considered particularly sensitive (IMHO, only use it for very long term keys like PGP, Org CAs, and TLS DHParam Keys).
However, when the sink caused by urandom gets to outpace the system, the entropy can drop significantly. That’s where this comes in. It’s fast enough at providing entropy you can fill the pool quicker to prevent the unblocking process from reusing bits to feed the CsPRNGs
Cheers,
-Jim
*** newer non-RHEL systems are starting to use getrandom since Kernel 3.15, but it has the same issue when you have large entropy requirements at scale
1 Like
I did a presentation about this 5+ years ago at the space. A good maxim in security is to not to roll-out your own crypto and use secure (verified) implementations based on vetted open standards. (NIST sp 800-90 withstanding). Thus my allusion to Bruce’s maxim,
I have used Ubuntu’s pollinate (entropy as a service) for the at scale entropy solution you referred to.
This isn’t quite what people mean when saying you shouldnt roll your own crypto; this is providing a faster seed source for the existing CsPRNG algorithms. I mean, Cloudflare uses friggin lava lamps to feed the CsPRNGs, but the CsPRNGs themselves still use standard algorithms.
This can, once built, also be run against the NIST validation suite prior to use. Using Entropy as a service is not always feasible (audit hell, trust/jurisdictional issues, etc). Using a local service still requires that remote service have enough Entropy for the number of clients, and you’re back at the same conundrum.
This RNG is the kind that would be used to feed the pollinate service rather than the client, should one use it.
EDIT N.B: For those not familiar with 800-90 reading this, the specific document of interest is here: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
This is one of a few parts of this standard, and the most recent as of this writing; it talks in particular about the Entropy sources that are suitable for seeding a CsPRNG (or DRNG/NRNG in their terms, of which CsPRNG is a subcategory, and those are covered in other documents for their respective parts of the standard).
