Skip to main content

How Cosmic Randomness Works

Randomness is one of those things that seems simple until you actually need it to be good. Most of the time, a pseudorandom number generator is perfectly fine. But when the stakes are high (ex. cryptographic key generation, provably fair systems, regulatory compliance), then "good enough" randomness isn't actually good enough.

Cosmic randomness is a different class of solution. It uses physical phenomena from outside the solar system to produce numbers that are genuinely unpredictable, and it does so in an environment where tampering is physically impossible.

True random vs. pseudorandom​

This distinction matters, so let's be precise about it.

Pseudorandom number generators (PRNGs)​

These are algorithms. You give them a seed value, and they produce a sequence of numbers that looks random. The output passes statistical tests, it's uniformly distributed, and for most practical purposes it behaves like random data. But it's deterministic. If you know the seed and the algorithm, you can reproduce the entire sequence. Every number is predictable in principle.

Good PRNGs (like ChaCha20 or AES-CTR in counter mode) are computationally indistinguishable from random to anyone who doesn't know the seed. For simulations, games, A/B testing, and most application logic, PRNGs are the right tool. They're fast, they're well-studied, and they work.

Early games randomness

Early game PRNGs are often quite ingenious given the constraints. A favourite example is Elite (1984), which used a Fibonacci linear feedback shift register (LFSR): a handful of bytes, shifted and XORed in a loop. The same tiny seed always produces the same game universe, requiring almost no memory and no floating-point math. The "randomness" was an illusion produced by arithmetic so simple it ran on a 1 MHz processor.

A fun example of how PRNGs may simply be not up to scratch is in early Pokémon games, where the player's movements and actions interact with the PRNG in a predictable way. Speedrunners use this to skip sections, jump to other parts of the game, and produce really strange things.

True random number generators (TRNGs)​

TRNGs derive their output from physical processes that are fundamentally non-deterministic. The numbers aren't computed from a seed: they emerge from physical phenomena that cannot be predicted or reproduced, even with complete knowledge of the system's state.

Common TRNG sources include thermal noise in electronic circuits, radioactive decay, and photon arrival times. What makes these "true" randomness sources is that the underlying physics is genuinely stochastic. There is no hidden variable, no algorithm, no pattern. The randomness is intrinsic to the physical process.

We stop here, before we drag you to the whole "free will" philosophical rabbit hole. Let's think about seeds instead.

The seed problem​

The security of any PRNG depends entirely on the quality of its seed. If the seed has good entropy, the PRNG output is strong. If the seed is weak (i.e. derived from a predictable source like the system clock, process ID, or insufficient entropy) the entire output stream is compromised.

This has caused real-world security failures. Debian's OpenSSL bug in 2008 reduced the effective seed entropy to about 15 bits, making every SSL key generated on affected systems trivially breakable. The Sony PlayStation 3 signing key was compromised because a "random" nonce was reused (effectively a constant seed). These aren't theoretical attacks, they're practical breaks caused by inadequate randomness.

A TRNG eliminates the seed problem at its root. There is no seed to be weak. The randomness comes from physics, not from an algorithm initialized with hopefully-good entropy.

Why you'd want a TRNG​

If PRNGs are good enough for most things, when do you actually need true randomness?

Cryptographic key generation. The security of any cryptographic system ultimately rests on the quality of its keys. A key generated from a PRNG seeded with a weak entropy source is vulnerable. If an attacker can guess or reconstruct the seed, they can reproduce the key. True randomness eliminates this attack vector entirely: there's no seed to guess.

Provably fair systems. Lotteries, gaming, random selection processes... anything where participants need to verify that the outcome wasn't manipulated. A PRNG-based system requires trust in the operator (they could know or control the seed). A TRNG-based system with public verifiability requires trust in nobody.

Compliance and audit requirements. Some regulatory frameworks (financial services, government, defense) mandate the use of hardware random number generators for specific operations. Having a verifiable, auditable source of true randomness simplifies compliance. Auditors can verify the randomness source rather than having to audit the entire PRNG implementation and seed management chain.

Blockchain and Web3. On-chain randomness is notoriously hard because blockchain environments are deterministic by design. Miners and validators can observe and potentially manipulate PRNG-based randomness, and as you may have guessed, this has happened already. An external, verifiable TRNG source provides randomness that no chain participant can predict or influence.

High-stakes decision systems. Random jury selection, clinical trial randomization, resource allocation, or any context where the fairness and unpredictability of the selection process is legally or ethically critical. The stakes may be high enough that "probably random" isn't sufficient: you need "provably random".

Cosmic radiation as an entropy source​

SpaceComputer's cTRNG (cosmic True Random Number Generator) uses cosmic radiation as its entropy source.

Cosmic rays are high-energy particles (mostly protons and atomic nuclei), the majority of which originates from outside the solar system. They come from supernovae, active galactic nuclei, and other violent astrophysical processes. By the time they reach Earth's orbital neighborhood, they arrive at random times, from random directions, with random energies. While its intensity increases with the distance to Earth (low earth orbits benefit partly from Earth's powerful magnetic field), it is still strong enough to be useful.

Cosmic radiation is:

Genuinely unpredictable. Cosmic ray arrival is a quantum-level stochastic process. No amount of information about previous arrivals gives you any predictive power over future arrivals. This isn't pseudo-randomness or chaos theory randomness, it's fundamental quantum indeterminacy. The same physics that makes radioactive decay unpredictable makes cosmic ray detection unpredictable.

Not reproducible. Two identical detectors in the same location will record different cosmic ray events. The process cannot be rewound or replayed. There is no "seed" that determines the sequence of events.

Not manipulable. You can't aim cosmic rays. You can't increase or decrease the flux in a targeted way. An attacker cannot influence the entropy source without, roughly speaking, controlling astrophysical processes light-years away. This isn't a circuit that someone could bias with a carefully applied electromagnetic field.

Abundant in orbit. Earth's atmosphere absorbs most cosmic radiation before it reaches the surface. In low Earth orbit, the flux is significantly higher, giving satellite-based detectors a rich and continuous entropy source. The satellite doesn't have to wait for events; they happen constantly. Ground-based cosmic ray detectors work too, but they get a fraction of the flux that's available in orbit.

Independent of the hardware vendor. The entropy comes from an external, astrophysical process, not from a property of the chip itself. This sidesteps concerns about hardware vendors introducing biases (intentionally or not) into on-chip entropy sources, a concern that has been raised about Intel's RDRAND instruction and other hardware RNGs.

The cTRNG pipeline​

Here's how cosmic randomness gets from deep space to your application:

1. Detection​

The satellite carries dedicated hardware for cosmic radiation detection. SpaceComputer currently supports cEDGE and Crypto2 payloads. These instruments detect individual cosmic ray events such as arrival time, energy deposition, and interaction characteristics of each particle.

The detectors operate continuously while the satellite is in orbit, accumulating events around the clock. Each event contributes entropy to the random number generation process.

2. Random number generation​

The raw detection data is processed onboard the satellite to extract entropy. The timing and characteristics of cosmic ray events are fed into a randomness extraction process that produces uniformly distributed random bytes. This processing happens on the satellite itself, in the physically isolated orbital environment.

The extraction process ensures that the output is properly conditioned. Even if the raw cosmic ray events have some statistical structure (which they do: the flux rate varies with orbital position, for instance), the extracted random bytes are uniform and independent.

3. Cryptographic signing​

Before the random data leaves the satellite, it's cryptographically signed using a key that resides onboard. This signature serves as a proof of origin: it binds the random data to the specific satellite hardware that generated it. If anyone modifies the data in transit, the signature verification fails.

This is a critical property. It's not just random data, but random data with a cryptographic guarantee of where it came from and that it hasn't been altered. The signing key never leaves the satellite, which means the physical isolation of orbit protects the integrity of the attestation chain.

4. Ground station download​

The signed random data is transmitted to ground stations during satellite pass windows (typically 5-15 minute windows as the satellite crosses overhead). The ground station receives the data and forwards it to Orbitport's terrestrial infrastructure.

Because data is generated continuously but downloaded in bursts, there's an inherent batching pattern. A single pass might deliver hundreds or thousands of cTRNG values generated since the last contact.

5. Distribution​

Orbitport makes the cTRNG data available through two channels:

The API. GET /api/v1/services/trng returns cTRNG values on demand. This is authenticated via Auth0 OAuth2 and gives you the most control over what you get, such as specific sources or specific quantities. Use this when you need programmatic access with source selection control.

The IPFS beacon. Every 60 seconds, Orbitport publishes a new block containing cTRNG values to IPFS. Each block includes a sequence number, timestamp, an array of random values, and a pointer to the previous block (forming a verifiable chain). The beacon is public: no authentication required, anyone can read it. Use this when you need a decentralized, publicly auditable randomness source.

6. Verification​

Any consumer of cTRNG data can verify the satellite's signature to confirm two things: the data was generated by the claimed satellite hardware, and the data hasn't been modified since generation. This is what makes the system auditable and trustworthy in a way that a traditional TRNG (which you have to trust the operator of) cannot match.

The verification is independent. You don't need to trust Orbitport, the ground station operator, or anyone in the data path. You verify the satellite's signature yourself, and the physical isolation of the satellite ensures the signing key hasn't been compromised.

Sources and fallback​

Not every API call results in fresh satellite data. Satellites have limited pass windows, and demand may exceed the rate at which new cosmic randomness arrives on the ground. Orbitport handles this through a source hierarchy:

aptosorbital (satellite source). Data generated directly by satellite hardware, with the full cryptographic signature chain. This is the gold standard: true cosmic randomness with provable origin. Availability depends on how recently the satellite has been in contact with a ground station.

derived (BIP32 derivation). When fresh satellite data isn't available, Orbitport can derive additional random values from a cosmic master seed using BIP32 hierarchical derivation. The seed itself was generated in orbit from cosmic radiation, so the derived values inherit its entropy. They're not independently generated cosmic random numbers, but they're derived from one in a cryptographically sound way. For most applications, the distinction between direct and derived cosmic randomness is immaterial.

IPFS beacon (public fallback). The beacon always has recent data and requires no authentication. It's a good fit for applications that don't need real-time values and prefer a decentralized access pattern.

The TypeScript SDK (@spacecomputer-io/orbitport-sdk-ts) handles this fallback chain automatically. You call the SDK, it returns randomness, and it picks the best available source without you having to manage the logic.

What makes this different​

There are other TRNGs in the world. Hardware random number generators based on thermal noise or shot noise are common and well-trusted. What makes cosmic randomness via satellite distinctive is the combination of properties:

  1. The entropy source is astrophysical. It's not a circuit on a chip that could theoretically be tampered with or biased by someone with physical access to the hardware. The randomness comes from cosmic ray events that no one controls.
  2. The hardware is in orbit. The physical isolation guarantee means the detection and generation process is beyond anyone's physical reach. No one can bias the detector, modify the extraction algorithm, or tamper with the signing key.
  3. The output is signed. Every cTRNG value carries a cryptographic proof of origin that anyone can verify independently. You don't have to trust the pipeline; you verify it.
  4. The distribution is public. The IPFS beacon makes cosmic randomness a public good. It's verifiable, auditable, and accessible without credentials.

No other randomness source provides all four of these properties simultaneously. For applications that need randomness they can prove is fair, prove is untampered, and prove was generated in an environment beyond physical access, cTRNG is purpose-built.

How cTRNG compares to other randomness approaches​

To put cosmic randomness in context, here's how it stacks up against other common randomness sources:

/dev/urandom and OS entropy pools. These are the standard source for most cryptographic operations. They mix entropy from hardware interrupts, disk timing, and other system events. They're excellent for general use, but the entropy quality depends on the system's environment, and there's no way to independently verify where the entropy came from. For most applications, /dev/urandom is the right choice. cTRNG adds value when you need provable, auditable entropy provenance.

Hardware RNGs (Intel RDRAND, ARM RNDR). These use on-chip entropy sources (typically thermal noise in ring oscillators) and are fast and convenient. However, they're black boxes: you trust the chip vendor's implementation. There have been concerns about whether some implementations could contain backdoors. cTRNG's advantage is that the entropy source is external and astrophysical, not embedded in a chip from a single vendor.

Drand and other distributed randomness beacons. Drand produces public, verifiable randomness through a distributed network of participants running a threshold BLS protocol. It's well-designed for on-chain randomness and public verifiability. The difference with cTRNG is the entropy source: Drand's randomness derives from the protocol's cryptographic assumptions, while cTRNG derives from physical cosmic events. Both are verifiable, but they have different trust assumptions.

VRFs (Verifiable Random Functions). VRFs produce random outputs that can be verified against a public key. They're useful in blockchain contexts (Chainlink VRF, for example) but are ultimately deterministic. Given the same input and key, they produce the same output. They provide verifiability but not true randomness in the physical sense.

Practical considerations for developers​

A few things to keep in mind when integrating cosmic randomness into your application:

Don't use cTRNG for everything. If you're generating a random color for a UI element, use Math.random(). cTRNG is for operations where the provenance and quality of the randomness actually matters: key generation, fair selection, compliance-sensitive operations. Using orbital randomness for trivial purposes wastes a scarce resource and adds unnecessary latency.

Batch when you can. Rather than requesting a single cTRNG value for every operation, fetch a batch and use them as needed. The IPFS beacon gives you 3 values every 60 seconds. The API can return multiple values per request. If your application generates keys or makes random selections periodically, maintain a small local pool of cTRNG values and draw from it.

Understand your freshness requirements. For most cryptographic operations, the age of the random value doesn't matter. A 256-bit random value generated an hour ago has the same entropy as one generated a second ago. The time it was generated doesn't affect its unpredictability. But if your use case involves a time-bound commitment scheme (e.g., "prove this randomness was generated after event X"), freshness matters, and you should use the API with source selection rather than the IPFS beacon.

Use the signature for verification, not just the value. If you're building a system where fairness needs to be auditable, store the full cTRNG response including the satellite's signature. This lets anyone verify after the fact that the randomness came from the satellite and wasn't substituted. The random value alone is just a hex string. The value plus its signature is the verifiable attestation that your security may depend on.

Plan for source variability. Your application might get aptosorbital (direct satellite) data most of the time and derived data occasionally. Both are good randomness, and their difference is in provenance, not quality. If your compliance requirements mandate direct satellite randomness specifically, check the source field in the response and handle the derived case appropriately (queue the operation, alert, fall back to a different workflow).

Further reading​