7 ms·
Convert standard Geiger counter to RNG
- gus_massa 3y agoHave you tested how good the random numbers are? I think they should be good, if the interval between clicks is much larger than the interval for the counter, but I may be missing something. Also, some source emit two particles and I don't know if there are interesting cascades of decompositions. If two consecutive clicks are close enought, I expect an uneven distribution on increasing secuances like 13478AC023489BC... Also, for very high click rates I expect missing double clicks.
- pxx 3y agoEdit: removed previous post. The increment happens as fast as the clock allows, which means any reasonable rate is much more than the cycle time. It delays 250us once it hears a click. I'm not quite sure why we bother with resetting the counter to 0 when it hears a click though.
- auspiv 3y agoThe linked previous project does: https://github.com/gbonacini/nuclear_random_number_generator https://github.com/gbonacini/nuclear_random_number_generator "I tested the randomness both testing the bytes and the single bits in the binary file created from the ASCII file from the appliance console ( see Appendix here or test directory for full result text). Accordingly with ENT man page: "If the percentage is greater than 99% or less than 1%, the sequence is almost certainly not random. If the percentage is between 99% and 95% or between 1% and 5%, the sequence is suspect. Percentages between 90% and 95% and 5% and 10% indicate the sequence is “almost suspect”", so having 85.17 percent in the bytes test and 60.52 percent in the bits test should be fine." Entropy = 7.998386 bits per byte. Value Char Occurrences Fraction 0 413451 0.500284 1 412981 0.499716 Total: 826432 1.000000 Entropy = 1.000000 bits per bit.
- nonrandomstring 3y agoThe source of radiation surely makes a difference. Directing the sensor at a small point source makes clustering higher than if pointing it up into space [0] and receiving the "planar wave" background radiation of the Universe. I took a while to figure this out when measuring the audio clicks and crackles from fire. I expect similar statistics to apply on a nuclear level (physicists please correct me). Within small, local sources common effects can be linked to common instigators. In other words events beget events. So a local variation in some variable sets off a bunch of related things [1]. As you sum this over an ever larger number of suitably decoupled sources, the central limit theorem starts to apply and what was bad uniform/even distribution becomes good Gaussian. In practice you need more than the theoretical >12 sources, but once you approach a few hundred uncorrelated sources the bell curve gets pretty good. [0] probably assume the sky/space is an infinite number of sources all at very large distances. [1] In the (dangerous) limit imagine a near critical mass of Uranium emitting bursts of chain cascades.
- pxx 3y agoNo this is all wrong. Fire crackles clearly depend on state. Nuclear decay is memoryless; decays are independent events. https://en.m.wikipedia.org/wiki/Radioactive_decay#Mathematics https://en.m.wikipedia.org/wiki/Radioactive_decay#Mathematic... > theoretical >12 sources What?
- nonrandomstring 3y agoThanks for the correction on nuclear state. It's hard to imagine anything having absolutely no state - but I guess a nucleus is not a "thing" as such, even if surrounded by lots of similar non-things. Does state not subsist in the total assembled mass in my example of near-critical collection?
- nonrandomstring 3y agoJust answering myself after some reading today. No, not really Because fission caused by free neutrons (which are rare) is something different from more common "spontaneous" radio-decay. That does beg the question; what is the cause that we don't yet understand, what lies behind little bits of the universe falling apart?
- ashleyn 3y agoI'm assuming the source is just ordinary background radiation. I'm wondering if, at such low levels, the geiger counter can accurately determine it enough to get a truly random output (as opposed to, some internal squelch on the unit creating predictable patterns). You probably would get far better randomisation ripping out americium from an old smoke detector and putting it by the geiger counter. (Just take note that residue on your hands from handling it may be toxic if ingested.)
- robotguy 3y agoMuch safer to buy Uranium on Amazon. That’s what I did. It really freaks people out when you pull out a small metal can with a RADIOACTIVE sticker on it. You can also get uranium glass beads and radioactive watch hands on Electronics Goldmine.
- mike_hock 3y agoHow about this? Preparation: Pick some measurement interval in which you'd expect a bunch of clicks, e.g. a minute. Count how many clicks you get in that interval. Then take 138% of that time and divide it by the number of clicks you counted. That will be the interval for your timer. RNG: Tune the counter so it rolls over approximately once per time interval you've computed above. We'll take two measurements per interval, b0 and b1. Every time the counter rolls over, reset b0 and b1 to zero. When a click occurs, set b0 to one if the counter is less than half its maximum value, otherwise set b1 to one (if multiple clicks occur, the respective bit just stays at 1). When the counter rolls over, check b0 and b1. If they're equal, do nothing (discard the measurement). If they're different, take b0 as a random bit that you've just created (discard b1, and then reset b0 and b1 for the next round). You can then combine multiple successive bits into random numbers of the width that you want.
- deleted 3y ago[deleted]
- anfractuosity 3y agohttps://www.fourmilab.ch/hotbits/how3.html https://www.fourmilab.ch/hotbits/how3.html is one algorithm I've seen before. I'm just wondering with a very active source with this algorithm, could you potentially get a sequence of 0 - 15 being generated? (I could well be misunderstanding) If a 'pulse' of activity from the source was detected at each interval
- LeoPanthera 3y agoI'm not a math or a CS expert, but I naively "designed" a PRNG which was simply repeatedly doing hash(random_seed+counter). Obviously you have to keep random_seed secure, and use a hashing algorithm that does not have easy collisions, but other than that, is there any actual downside to this method?
- lxgr 3y agoOne important thing this does not achieve is forward and backward secrecy. A proper PRNG periodically irreversibly mutates its internal state (which gives you the property of not being able to retrieve past outputs in case of a point-in-time system compromise) and also incorporates additional entropy into its internal state whenever it becomes available (which makes it impossible to predict all future outputs after a point-in-time compromise). Backward secrecy can be achieved by completely replacing your current state with some hash function of it, i.e. completely deterministically; forward secrecy needs additional entropy, so it's not always feasible.
- er4hn 3y agoYou do have a few details to worry about such as the size of the random_seed, and how much you can output before you need to get a new seed. There's also a problem that if the state of the rng is exposed at any point, all past generated values can be determined (oh, it's currently on {random_seed="foobar", ctr=5}, I can predict the prior values.) But it is very close to the US Fed approved HASH_DRBG, under NIST SP 800-90A, section 10.1.1 here: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... . The big problem with PRNG algorithms is that, imo, determining how good they are feels like a bit of a black art. You can have things that measure as having high entropy very easily that have very predictable inputs or can be easily broken. It's always been a nit of mine when trying to analyze how good a PRNG is.
- kloch 3y agoAnalysis of PRNG's is difficult and very important: https://www.pcg-random.org/posts/does-it-beat-the-minimal-standard.html https://www.pcg-random.org/posts/does-it-beat-the-minimal-st...
- stcredzero 3y agoNot a crypto expert, but here's my understanding of the problem. The system just has to gain bits of entropy from the physical randomness source faster than the hardware and software leaks them. So one could feed the entropy into a stream cipher with the right characteristics. What if one just counted the number of clicks, modulo 2? Then one could take the output of ChaCha20 or Salsa20 stream ciphers and every N outputs of the stream cipher, increment the stream cipher's counter bits 0 or 1 times. One would also have to re-key the stream cipher periodically. (Maybe after gathering 128 bits of output from the Geiger counter in another register, then using that.)
- lxgr 3y ago> So one could feed the entropy into a stream cipher with the right characteristics. Certainly, but your proposed scheme does not feed entropy back into the stream cipher, it just offsets its output. This can be trivially broken if the stream cipher key ever leaks. A better solution would combine (ideally securely hash) the stream cipher key with a relatively large (i.e. on the order of > 100 bits) number of bits.
- tptacek 3y agoI mean this is true, but it's also true that every cipher can be trivially broken if its key leaks. Yes: you want to rekey regularly (and that's not complicated). But whatever circumstance allowed your state to leak in the first place is most probably repeatable by an attacker, so you likely have much bigger problems than PRNG design. If you want to snipe at people for freelancing their own CSPRNGs, the better point to make is that people should be relying on the OS's secure random generator to the exclusion of everything else; there are systems security reasons to avoid userland CSPRNGs. But I think for the most part these are just people enjoying working out how a CSPRNG works. Which, mazel tov!
- stcredzero 3y agoCertainly, but your proposed scheme does not feed entropy back into the stream cipher, it just offsets its output. Which effectively introduces entropy into the output, as well as to the internal state of the stream cipher. This can be trivially broken if the stream cipher key ever leaks. This is a trivial restatement of how symmetric ciphers are supposed to work.
- filterfiber 3y agoSeveral of the GQ counters have serial access, does anyone know if you can get the individual events from those?
- sethaurus 3y agoSlightly off-topic: I’ve been thinking about getting a Geiger counter as a hobbyist toy. Anyone got a recommendation?
- ThePowerOfFuet 3y agoGamma-Scout, Alert model.