[HN Gopher] Convert standard Geiger counter to RNG
___________________________________________________________________
Convert standard Geiger counter to RNG
Author : propmaster
Score : 22 points
Date : 2023-11-13 10:06 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gus_massa wrote:
| Have 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 wrote:
| Edit: 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 wrote:
| The linked previous project does:
|
| 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 wrote:
| The 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 wrote:
| No 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#Mathematic.
| ..
|
| > theoretical >12 sources
|
| What?
| nonrandomstring wrote:
| Thanks 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?
| ashleyn wrote:
| I'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.)
| anfractuosity wrote:
| 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 wrote:
| I'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 wrote:
| One 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 wrote:
| You 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.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 wrote:
| Analysis of PRNG's is difficult and very important:
|
| https://www.pcg-random.org/posts/does-it-beat-the-minimal-
| st...
| tptacek wrote:
| This isn't a security analysis, and PCG isn't a secure
| random number generator, but it is the case that you can
| fashion a crude secure random number generator out of a
| sufficiently large state and a cryptographic hash.
| aljarry wrote:
| Depends on the usage. Commonly available "legit" PRNGs have
| uniform distribution, even over long range of numbers.
|
| Wikipedia has a list of interesting tests you could do to
| confirm you PRNG:
| https://en.wikipedia.org/wiki/Pseudorandom_number_generator#...
| where first two are interesting for a non-cryptographic PRNG.
| Verdex wrote:
| IIRC there's a PRNG talk for videogames where they mention your
| method:
|
| https://www.youtube.com/watch?v=LWFzPP8ZbdU&t=4s
|
| There are downsides, but for videogames, the speaker decided
| that this wasn't that bad of an idea.
| stcredzero wrote:
| Not 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 wrote:
| > 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 wrote:
| I 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!
| tptacek wrote:
| I don't understand what you mean by "leak" here. You can
| definitely make a secure random bit generator with a stream
| cipher. Once it's fully initialized/seeded, it's practically
| never going to run out of random bits.
| filterfiber wrote:
| Several of the GQ counters have serial access, does anyone know
| if you can get the individual events from those?
___________________________________________________________________
(page generated 2023-11-13 23:01 UTC)