Using Nuclear Decay As Random Number Generator Source For An MCU

Computers are amazing at many things: math, memes, and turning coffee into firmware. But “being truly unpredictable”?
That’s not their natural vibe. A microcontroller (MCU) can generate pseudorandom numbers all day longnumbers that
look random until someone with enough context (or malice) predicts them. If your project touches cryptography, secure
communications, authentication tokens, or even “I really don’t want my game’s loot drops to feel rigged,” you eventually
run into the same awkward question:

Where do the first truly random bits come from?

One classic answer is to borrow randomness from the physical world. Thermal noise. Clock jitter. Chaotic lava lamps.
And yesradioactive decay. It’s the original “you can’t possibly guess this” phenomenon, because at the level we care
about, each decay event is governed by quantum mechanics. That makes nuclear decay a compelling entropy source for a
true random number generator (TRNG), especially when you want an MCU to have its own independent “dice.”

This article walks through how nuclear decay can be used as a random number generator source for an MCUwhat it means,
what the data pipeline looks like, where bias creeps in, how to condition it responsibly, how to sanity-check the output,
and why safety/legal considerations matter more than your soldering iron.

Why Nuclear Decay Is a Gold-Plated Entropy Source

Radioactive atoms “decide” to decay at times that are fundamentally unpredictable in the way we normally mean by
unpredictable. Over many atoms, the average decay rate is stable, but the exact timing of each event is not
something you can forecast. If you detect individual decay events (for example, as pulses from a Geiger-Müller tube),
you can treat them like nature’s tiny, impartial coin flipsassuming you do the engineering work to extract clean bits.

In practice, decay events arrive like a random “rain” of pulses. Statistically, the count of events in a fixed interval
often behaves like a Poisson process, and the time between events follows an exponential distribution. That’s great for
entropy, but it also means the raw stream is not automatically “perfect bits.” You’re harvesting unpredictable timing,
then shaping it into unbiased, usable randomness.

TRNG vs PRNG: Why Your MCU Can’t Just “Wing It”

Most microcontrollers can implement a fast PRNG (pseudorandom number generator): linear congruential generators,
xorshift variants, or higher-quality algorithms. These are fine for simulations, non-security games, and “random LED
sparkle mode.” But they’re not inherently unpredictable. Given the internal state (or enough outputs), an attacker can
often reconstruct future outputs.

A true random number generator (TRNG) starts with a physical entropy source. Many modern MCUs already include
TRNG peripherals, often based on ring-oscillator jitter or analog noise, and vendors provide documentation and validation
guidance. But external entropy sources still matter when you want:

• Independence: a randomness source not tied to the MCU’s silicon design or supply chain.
• Diversity: combining multiple entropy sources to reduce systemic risk.
• Education: you want to build the “physics-to-bits” pipeline and learn what real randomness costs.

Nuclear decay is attractive because it’s physically distinct from typical on-chip TRNG designs. It’s also dramatic. Your
device literally listens to the universe whisper “click… click… click…” and turns it into cryptographic seeds.

How You Turn Decay Events into Bits (Without Lying to Yourself)

The core idea is simple: detect discrete radiation events, measure some property that is hard to predict (often timing),
then apply conditioning to produce unbiased bits suitable for seeding a cryptographic DRBG
(deterministic random bit generator).

Step 1: Detect Events (Pulses, Not Vibes)

A common detector is a Geiger-Müller tube and front-end circuit that outputs a digital-ish pulse for each detected event.
Other detectors (scintillators + photodiodes, semiconductor detectors, etc.) can also yield pulses or analog waveforms,
but the MCU-friendly path is an event pulse you can count or timestamp.

Important reality check: detection hardware adds its own behaviordead time, afterpulses, thresholds, temperature drift,
and susceptibility to electromagnetic noise. None of this ruins the concept, but it means you should treat raw pulses as
“noisy observations of a random process,” not as perfect bits.

Step 2: Extract Unpredictability from Timing

The most common entropy harvest is timing. Your MCU can run a free-running high-resolution timer. Each time a pulse
arrives, record the timer value (or the delta since the last pulse). The least significant bits (LSBs) of those timestamps
often carry the most entropy because they capture fine-grained jitter and the unpredictable arrival time of the next event.

You can also combine multiple measurements:

• Inter-arrival deltas: time between pulses, then use selected bits.
• Counts per window: number of pulses in short fixed intervals.
• Mixing sources: combine decay timing with oscillator jitter or ADC noise for extra robustness.

Step 3: Remove Bias (Because Physics Is Random, Electronics Are Not)

Raw extracted bits frequently exhibit bias or correlation. That’s normal. The job of a TRNG design is to measure, bound,
and reduce that bias with a well-understood conditioning stage.

A classic debiaser is the Von Neumann extractor:
take bits two at a time; if they match, discard; if they differ, output the first bit.
It’s simple and surprisingly effective when assumptions hold, but it reduces throughput and doesn’t fix every kind of
correlation.

Modern practice often uses a cryptographic hash (or MAC) as a conditioning function: collect a block of raw samples,
hash them, and use the digest (or part of it) as conditioned output. This doesn’t magically create entropy, but it
“compresses” unpredictable input into a uniform-looking outputassuming enough min-entropy exists in the input.

Step 4: Expand with a DRBG (Fast Output, Same Root Entropy)

Once you have a reliable entropy estimate and a clean seed, you usually feed it into a DRBG so your MCU can produce
random numbers quickly. This is the standard architecture recommended in well-known guidance: an entropy source plus
deterministic generation, with ongoing health checks.

Translation: the decay stream is your “seed factory,” not your “firehose.” Let it generate high-quality seeds, then let a
DRBG generate as many random bytes as your application needs.

A Practical MCU Architecture for a “Nuclear TRNG”

Here’s a realistic, MCU-friendly pipeline that stays honest about what’s going on:

1. Pulse input stage: detector provides pulses; MCU receives via interrupt or timer capture input.
2. Raw sample collection: store timestamps (or deltas) into a ring buffer.
3. Health tests: continuous checks for “stuck” behavior, abnormal rates, and obvious failures.
4. Conditioning: hash a block of samples to generate a seed (or seed material).
5. DRBG: produce random bytes for the application; reseed periodically.

If you want a mental image, think of it as a small factory:
radiation clicks go in one side, quality-control inspectors stand in the middle, and cryptographic-grade randomness comes
out the otherstamped and packaged.

Minimal Pseudocode (Conceptual, Not a Wiring Recipe)

Notice what’s missing: “trust me, bro.” The design assumes you’ll test, monitor, and periodically reseed.

Safety and Legal Reality Check (US-Context, No Heroics)

Radioactive materials deserve respect, not bravado. Ionizing radiation can damage tissue and DNA, and “tiny” does not mean
“toy.” In the United States, radioactive sources are regulated, and even consumer products that contain small amounts
(like some smoke detectors) are intended to be used as designednot dismantled or repurposed.

If you explore nuclear decay as an entropy source, do it the responsible way:

• Use off-the-shelf radiation detection equipment designed for safe operation.
• Do not tamper with consumer devices that contain radioactive sources.
• Follow applicable regulations and disposal rules and use properly sealed, approved sources if any are used at all.
• Prefer background radiation for experimentation when feasibleslower, but avoids “where did you get that?” problems.

The goal here is to learn and to build a reliable entropy pipelinenot to turn your workshop into a regulatory headache.

Health Tests: How You Know It’s Working Today, Not Just in Theory

A TRNG design is not complete without health tests. An entropy source can fail silently: a cable comes loose,
the detector saturates, an interrupt stops firing, a threshold drifts, or the environment changes. Good designs detect
these problems quickly and refuse to output “random” data when the entropy source is unhealthy.

Practical health checks you can implement on an MCU include:

• Startup sanity checks: confirm pulses are arriving and values are not constant.
• Continuous repetition checks: detect suspiciously repeated samples or patterns.
• Rate monitoring: ensure event rates remain within expected bounds (account for noise and environment).
• Adaptive thresholds: track slow drift without letting a broken source hide behind “normal variance.”

When you want deeper validation, you can record raw output and run statistical analysis offline using widely discussed
randomness test suites. These tests don’t “prove” randomness, but they can detect many forms of bias, correlation, and
implementation mistakes. They’re particularly useful when you compare:

• Raw event timing samples
• Post-extractor / post-hash conditioned output
• Final DRBG output

A comforting pattern is: raw data looks messy (and maybe biased), conditioned data looks much cleaner, DRBG output looks
excellentand health tests keep you from shipping garbage when the detector cable falls out at 2 a.m.

Throughput: How Many “Nuclear Bits” Can You Actually Get?

Throughput depends on event rate. Background radiation yields relatively low counts, while stronger sources yield higher
ratesbut “stronger source” is exactly where safety and compliance become non-negotiable. Even with a decent pulse rate,
remember that:

• Debiasing methods (like Von Neumann) discard data.
• Conditioning (hashing) compresses inputs into fewer output bits.
• The best practice is to use decay as a seed source and expand via DRBG.

In other words, expect “enough entropy to seed and reseed securely,” not “gigabits per second of radioactive randomness.”
If you need lots of high-rate randomness, you’ll likely rely on a hardware TRNG peripheral, a dedicated RNG chip, or both.

Why Built-In MCU TRNGs Might Be the Smarter Default

Before you build a tiny shrine to quantum uncertainty, it’s worth acknowledging: many modern MCUs already ship with TRNG
peripherals. Vendors document their TRNG design, recommended usage, and (often) provide test/validation guidance. That can
be a big win for time-to-market and reliability.

That said, a healthy skepticism is warranted. Hardware RNG systems can have bugs, misconfigurations, or edge cases.
Real-world security history includes incidents where hardware RNG behavior surprised people in unpleasant ways. The lesson
isn’t “never trust hardware RNG.” The lesson is “treat randomness like a critical subsystem: validate, monitor, and use
defense-in-depth.” Combining independent entropy sourceslike an on-chip TRNG plus an external physical sourcecan be a
reasonable strategy in high-assurance designs.

Specific Use Cases Where Nuclear-Seeded Randomness Shines

1) Cryptographic Key Generation and Device Provisioning

If you generate long-term keys on-device, your initial entropy matters. A decay-based seed can be mixed into your entropy
pool to strengthen device uniqueness and reduce dependency on any single source.

2) Secure Nonces, Salts, and Session Tokens

Many cryptographic failures come from weak nonces and predictable salts. A reliable seed + DRBG setup can prevent “oops,
everyone got the same nonce” disasters.

3) Demonstrations, Labs, and Teaching

Nothing sells “entropy is real” like watching physical event timing become bits. It’s a powerful educational project
precisely because it forces you to handle bias, conditioning, and testingthings many tutorials skip.

4) Art and “Randomness With a Story”

Some projects want randomness that’s not just random, but delightfully weird: “these patterns are driven by background
radiation.” That’s the kind of sentence that makes a gallery placard do push-ups.

Design Gotchas (AKA: The Places Randomness Goes to Hide)

• Dead time and afterpulsing: detectors can have recovery periods that affect timing distribution.
• EMI and coupling: your “random” pulses might accidentally correlate with switching regulators or nearby motors.
• Timer resolution: if your timer is too coarse, many events quantize to similar values and entropy drops.
• Overconfidence: passing a few tests doesn’t guarantee unpredictability in every scenario.
• Operational drift: temperature, supply variation, and aging can change behavior over time.

The antidote is consistent: measure, monitor, and condition. Randomness is not a vibe; it’s an engineering discipline.

Real-World Experiences: What Builders Learn When They Try This

People who experiment with nuclear-decay-based entropy sources often describe the first “aha” moment as surprisingly
emotional: the device starts counting pulses and you realize you’re observing individual ionizing eventslittle
unrepeatable blips that are happening whether or not your firmware is ready for them. That’s when the project stops
feeling like “random numbers” and starts feeling like “physics is talking to my MCU.”

The second lesson usually arrives right after the first: raw data is messy. Builders commonly report that the first
extracted bitstream looks biased or “clumpy” when plotted. That’s not a failure of quantum mechanics; it’s a
reminder that detectors and timing circuits have personalities. Some pulses have slightly different widths. Some
inter-arrival deltas repeat more often than intuition expects. Some environments add periodic noise (a nearby power
supply, a fluorescent light ballast, a laptop charger). It’s a great humbling experience because it teaches a key truth:
entropy is present, but you still have to do the work to harvest it cleanly.

The third lesson is about throughput expectations. Many hobbyists start with the dream of a nonstop stream of random
bytes, then discover that responsible extraction trades speed for quality. If you use a simple debiasing approach, your
output rate can drop sharply. If you hash blocks of samples into seeds, you’ll generate fewer output bits than the number
of raw measurements you collect. That’s when the architecture “clicks” (sometimes literally): decay is best used to seed
a DRBG, not to replace it. The DRBG becomes your efficient engine, and the radioactive stream becomes your trusted fuel.

Another common experience is learning to love health tests. Early prototypes might “work” beautifully until they don’t.
Someone bumps a cable, the detector board browns out, or an interrupt pin gets reconfigured by a careless refactor. When
that happens, the MCU can keep emitting numbers that look random to a casual observer but are actually predictable or
frozen. Builders who’ve been burned once tend to become very strict: the entropy source must prove it’s alive at startup,
prove it’s still alive continuously, and fail closed when it’s not.

Finally, responsible teams mention the safety mindset shift. The project can be fun, but it also forces discipline:
using proper detection equipment, respecting regulations, and avoiding shortcuts like dismantling consumer devices. In the
best cases, the project becomes a gentle “grown-up” version of hobby electronicswhere the thrill comes not from risky
materials, but from careful design, repeatable measurements, and the satisfaction of building a randomness pipeline you
can defend with evidence.

If you come away thinking, “Wow, this is more work than calling rand(),” congratulationsyou now understand why
good randomness is valuable. And why, when you do it right, it’s one of the most satisfying subsystems you’ll ever ship.