Frequently Asked Questions

Real Random is a physical true random number generator (TRNG) that produces entropy from dice tumbling in viscous fluid, captured by high-speed computer vision. Unlike algorithmic pseudo-random number generators (PRNGs) that rely on mathematical formulas and can produce predictable patterns, Real Random draws from physical chaos: fluid turbulence, mechanical collisions, and positional variance across multiple dimensions. The result is entropy that is directly observable and verifiable.

Real Random augments your existing systems rather than replacing them. It acts as an external entropy source that feeds your current HSMs, key management systems, and certificate authorities. Integration typically requires about four lines of API code. There is no rip-and-replace. Your existing encryption stack stays in place, and Real Random strengthens it by providing a higher-quality entropy input at the foundation.

Real Random uses a pre-generated entropy pool rather than producing randomness in real time per request. API response times are sub-millisecond when deployed in-rack and low single-digit milliseconds over authenticated channels. For most enterprise workloads like key generation, certificate issuance, and session tokens, the bottleneck is never the entropy source. The system is designed so that entropy is always available when your application calls for it.

No. The entropy generation hardware isolates its noise sources (LED illumination, pump mechanics, photon behavior) from environmental interference. NIST noise-source isolation principles guide the design. A randomized pump feedback loop adds an additional layer of unpredictability that is independent of ambient conditions. This was validated through independent testing at Rochester Institute of Technology.

The system captures hashed pixel data from physical dice positions, not simple pip values. An entropy-fed feedback loop continuously varies pump speed and agitation patterns, and health tests validate output quality before concatenation and delivery. Because the entropy originates from a physical, non-deterministic process rather than a mathematical formula, there is no seed to reverse-engineer and no algorithm to model. This is what makes physical entropy fundamentally different from software-based alternatives.

No system should be described as unhackable, and we do not make that claim. What Real Random does is eliminate a specific, well-documented vulnerability: the use of predictable or weak entropy in key generation. Because our entropy comes from a physical, non-deterministic source, there is no algorithmic seed to compromise. OAuth bearer tokens are generated from our own entropy. With on-premises hardware, entropy never leaves your network, and API delivery runs over authenticated, encrypted channels. Security is built in layers, and Real Random strengthens the foundation layer that every other layer depends on.

The hardware includes a full sensor suite: door sensors, power monitors, and environmental detectors feeding a centralized admin dashboard. If tampering is detected, the device wipes itself automatically. A kill switch provides manual override. Health tests run continuously to detect any drift or anomaly in output quality. The system is designed around "don't trust, verify" at the hardware level.

That depends on how you deploy. With the rack appliance or portable unit, the hardware sits in your environment. Entropy is generated, consumed, and stays local, and nothing leaves your facility unless you configure it to. For organizations with data sovereignty requirements, residency follows the customer because the hardware is physically in your environment. With Entropy-as-a-Service, entropy is delivered from Real Random hardware over authenticated, encrypted API calls. In every model, camera images used for entropy capture are never stored. They are overwritten with the next frame immediately.

Real Random monitors entropy consumption patterns and flags anomalies. If an application suddenly draws entropy at an unusual rate or pattern, that signal can be exported into your existing IDS or SOC pipeline. However, entropy is not a breach detection tool on its own. It strengthens key material and can surface unusual consumption behavior, but incident detection and response remain the job of your security stack.

Software random number generators, even well-designed CSPRNGs, are only as strong as their initial seed. If the seed comes from a low-entropy source (common during boot, in virtualized environments, or on constrained IoT devices), the output can be predictable. Physical entropy from Real Random is directly observable. You can see the dice tumbling. You can verify the output through independent statistical testing. That transparency is the core of the "trust but verify" principle: you are not relying on a black box.

Real Random offers three delivery models, all powered by the same patented entropy source:

• Entropy-as-a-Service (EaaS): True physical entropy delivered over an encrypted REST API through the Real Random developer portal. No hardware to install, so teams can prototype against their actual stack the same day they sign up.
• 2U rack appliance: Rack-mounted generators installed in your data center or secure facility. Entropy is served locally through the same REST API, with no dependency on external cloud services or third-party networks.
• Portable hardware: A compact, ruggedized unit for lab, field, and edge deployments, with no network dependency.

Many teams start with the API to evaluate and integrate, then move to on-premises hardware as volume or compliance needs grow. For hardware deployments, sizing is straightforward: you provide your key volume and cryptographic operations, and a stochastic model returns the number of devices needed plus a hot spare for failover.

The system is built with dual boards per chassis for automatic failover. Hot spares are supplied and designed for fast swap. Health tests with tamper sensors run continuously, and the device maintains up to 30 days of stored entropy as a buffer. If any anomaly is detected, the system alerts through the admin dashboard before entropy availability is affected. Mean time between failures is rated at five years, with parts rated for extended service.

Yes. Real Random feeds entropy into your existing cryptographic infrastructure through standard interfaces. It supports OpenSSL and PKCS#11 integration paths, and the SDK roadmap includes Python, Java, C++, and .NET. The integration model is component augmentation: Real Random provides the entropy, and your existing tools continue to handle key generation, storage, and lifecycle management.

Yes. The standard deployment is an appliance in the customer's own rack with entropy delivered locally. For service providers, the model supports a provider-hosted appliance delivering entropy over authenticated, encrypted channels. The key point is that entropy is always generated by dedicated hardware, never by software alone, regardless of the hosting arrangement.

If your cryptographic operations run through a core provider like a managed banking platform, the core provider becomes the integration point. Real Random works at the infrastructure layer, so the conversation shifts to your core provider's architecture and how entropy feeds their key management. We work with organizations to identify the right entry point, whether that is directly in your environment or through the provider that manages your stack.

It depends on your key volume. The sizing method takes your cryptographic operations as input, such as how many keys you generate, how often you rotate them, and what your peak load looks like. From there, a model returns the device count plus a recommended hot spare. A mid-size core provider serving several hundred client institutions, for example, might need a handful of devices. We scope this during the no-cost proof of concept.

Real Random has been independently tested using three industry-standard randomness test suites: the NIST Statistical Test Suite, the DieHarder suite (developed at Duke University), and the Fourmilab ENT analysis. Fourmilab ENT measured 0.999996 bits per byte, effectively the theoretical maximum of 1.0. Rochester Institute of Technology conducted independent academic validation of the methodology and results.

The numbers are only part of the story. Most entropy sources, from sealed chips to remote randomness services, ask you to trust a process you cannot inspect. Real Random's source is physical motion you can watch, and its output is open to independent testing. That combination of a visible source and measurable output is what makes it a stronger foundation for your keys.

Real Random is currently in the NIST Entropy Source Validation (ESV) process through atsec, an accredited testing laboratory. The ESV certification validates that an entropy source meets the requirements of NIST SP 800-90B for use in cryptographic systems. This certification is the recognized standard for entropy sources used in FIPS-validated cryptographic modules.

FIPS 140-3 requires that the entropy source inside a validated cryptographic module be validated under NIST SP 800-90B through the ESV program. CNSA 2.0 pushes national security systems in the same direction. That puts the source of your randomness under the same scrutiny as your algorithms. For organizations subject to federal requirements, or in regulated industries where FIPS-validated cryptography is expected, the entropy behind your keys has to hold up to that review.

Real Random helps organizations meet these requirements by adding a layer of entropy generated from physical motion, dice tumbling in fluid, underneath the HSMs, key management systems, and crypto libraries you already run. Your existing modules stay in place. The randomness feeding them gets stronger, observable, and easier to document for auditors.

Observability is one layer of trust. You can see that the physical process is genuinely chaotic, which is something no sealed hardware module or software algorithm can offer. But for regulated sectors, visual verification alone is not sufficient. Statistical testing and the ESV certification provide the formal, repeatable proof that auditors and compliance teams require. The two work together: you can see the source, and you can independently verify its output.

Yes. PQC algorithms like ML-KEM and ML-DSA require high-quality entropy to generate secure keys, just like classical algorithms do. In fact, some PQC algorithms require more entropy per key than their predecessors: ML-KEM needs 384 bits of entropy per operation compared to 256 bits in many classical schemes. The algorithms themselves are designed to resist quantum attacks on the math. But if the entropy feeding those algorithms is weak or predictable, the keys they produce are still vulnerable. Real Random is the entropy layer that makes PQC trustworthy.

Three forces are converging. First, FIPS 140-3 puts the entropy source under formal review: validated modules must rely on entropy that meets SP 800-90B, and regulated industries are working through that re-validation now. Adding a layer of physical entropy is one of the simplest ways to strengthen that foundation without replacing your modules. Second, post-quantum cryptography standards are finalized and adoption is underway, which means the entropy requirements for key generation are increasing. Third, the "harvest now, decrypt later" threat model means adversaries are already collecting encrypted data to break later with quantum computing. Organizations that wait until quantum computers arrive will be years behind on a migration that historically takes a decade.

Not directly, and not today. Cyber-insurance pricing has not yet caught up to entropy-source quality as a rated factor. Without a regulatory trigger that specifically ties premiums to cryptographic entropy, this is unlikely to change in the near term. The value of stronger entropy shows up in risk reduction: fewer weak keys, fewer predictable outputs, and a stronger foundation under your entire cryptographic stack. The cost argument is about avoiding the catastrophic failure that weak entropy can cause, not about a line item on an insurance renewal.

Real Random uses an OPEX model, not a large upfront hardware purchase. Pricing is determined from the results of meeting the customer requirements in the 30-day proof of concept. There is no flat license fee and no six-figure hardware purchase. The no-cost proof of concept includes device installation in your environment, 30 days of operation, and a written executive readout with entropy quality results and integration findings.

That is a common and reasonable position. But the entropy problem is not a future problem. Weak or predictable entropy is a vulnerability today, independent of quantum computing. Documented failures in RSA key generation, the Debian OpenSSL bug, and boot-time entropy shortages on IoT devices have all caused real-world security incidents using classical attacks. Quantum computing adds urgency to the timeline, but the value of stronger entropy is immediate.

Real Random was recognized by Gartner as a Cool Vendor in Data Security 2025 (ID G00839402). The company holds 6 U.S. Patents Granted and 27 international patent rights. Independent academic validation has been conducted at Rochester Institute of Technology and Duke University. The no-cost proof of concept is designed specifically so that you can evaluate the technology in your own environment before making any commitment.

That gap is exactly the problem. Cryptographic Bills of Materials (CBOMs) typically inventory algorithms, key lengths, and certificate lifespans, but they rarely assess the quality of the entropy source feeding key generation. This means an organization can pass a CBOM audit while still running on weak or predictable randomness. A five-step entropy-source assessment fills that gap and often reveals dependencies that no other part of the security review catches.

The proof of concept includes a Real Random appliance installed in your environment, 30 days of operation against a scoped workload, and a written executive readout at the end. The readout covers entropy quality measurements, integration findings, and a comparison against your current entropy sources. The POC is scoped to one high-value cryptographic flow, such as key generation for payments or identity, so that the results are meaningful and directly tied to a real part of your infrastructure.

Start with an entropy-source assessment. This is a structured review of where your cryptographic keys come from today, what entropy sources feed them, and where the gaps are. It takes the form of a scoped engagement, not a free consulting session, and produces a written deliverable your security and compliance teams can act on. From there, the proof of concept targets the highest-priority flow the assessment identifies.

The API integration itself is minimal, typically about four lines of code. The broader timeline depends on your environment: how your HSMs or KMS systems accept external entropy, what testing and change-management processes you follow, and whether the deployment runs through your own infrastructure team or a managed service provider. Most organizations move from assessment to production deployment through a phased rollout: assessment, integration, testing, and go-live.

The evaluation typically involves security architecture or engineering (who own the cryptographic stack), infrastructure or platform teams (who manage the physical or cloud environment the appliance runs in), and compliance or risk (who need the validation and audit trail). For organizations where cryptography runs through a core provider or managed platform, the provider's architecture team is the primary integration contact.