Quantum entropy you own

Strong keys start with strong randomness.

Every key is only as good as the randomness it came from. SQP Sovereign Entropy is a client-owned appliance that delivers health-tested, quantum-sourced seeds to every workload in every cloud, over a post-quantum secured channel, at the moments randomness is weakest.

Contact salesSee how it works
~32,768

possible keys left by the Debian OpenSSL random-number flaw (CVE-2008-0166)

~70%

of serious vulnerabilities are memory-safety bugs (Microsoft, Google). Our entropy server is written in Rust

0

keys ever seen by the appliance. It supplies seeds, never keys

The problem

Weak randomness silently breaks strong cryptography

Post-quantum algorithms protect you only if their keys can't be guessed. When the random numbers behind a key are weak or repeated, the strongest algorithm fails quietly.

Debian, 2008

A packaging change left OpenSSL on Debian systems with roughly 32,768 possible keys. SSH and TLS keys generated for almost two years could be guessed.

Internet devices, 2012

Researchers found large numbers of devices sharing or exposing keys because they generated them at boot with too little entropy ("Mining Your Ps and Qs").

The cloud makes it worse

Cloning, restoring and scaling copy the "random" state

Cloud speed and automation create moments a physical server rarely faces. Restore two machines from the same snapshot and they can produce the same "random" values, and the same keys.

Without fresh entropyRestored copies share the same "random" stateSnapshotIncludes RNG stateRestored VM AGenerates a TLS keykey 9f3a…c21Restored VM BGenerates a TLS keykey 9f3a…c21Identical keys: one compromise breaks both With SQP Sovereign EntropyEach copy is reseeded on restore, before it creates keysSnapshotIncludes RNG stateRestored VM AGenerates a TLS keykey 4c81…e07Restored VM BGenerates a TLS keykey b2d9…71fFresh seedFresh seedCopies diverge before they create secrets Illustrative key values

Early boot

A new VM has had little time to gather entropy, yet SSH host keys and TLS sessions start almost immediately.

Containers and serverless

Workloads share a host kernel or run in short-lived sandboxes with no view of how entropy was gathered.

Opaque trust boundary

Guest entropy comes from the provider's hypervisor and hardware. You must trust it but can't audit it.

Multi-cloud inconsistency

Several providers mean several entropy designs, with no single policy, validation record or audit trail.

What NIST recommends

Entropy as a service, done the way NIST describes

NIST identifies low-entropy randomness as a direct cause of cryptographic failure and points to quantum phenomena as the best source of true randomness, delivered as a network service.

  • The service supplies entropy but does not generate keys.
  • The server gains no insight into client keys.
  • Entropy is paired with trustworthy timestamps.
  • Trust should not rest on a single operator.

But delivery over a network adds risks

  • Harvest now, decrypt later: seeds sent over classical key exchange could be exposed later.
  • Replay and substitution: without signatures and freshness, old or chosen values could be injected.
  • Memory-safety flaws: a C or C++ service handing out seeds must not be the weakest link.
  • Unvalidated cryptography: regulated teams need FIPS evidence.
  • Third-party dependence: a hosted service leaves you without control of availability, location or audit.

SQP Sovereign Entropy is built to close each of these.

Architecture

A quantum entropy root you own

A hardened, tamper-evident appliance pair in your data center, colocation facility or enclave, fitted with one or more quantum random number generators and scaled to demand.

Raw output is continuously health-tested to NIST SP 800-90B and conditioned; a failing source is taken out of service rather than delivering degraded output.

Your data center: client-owned, client-controlled Quantum RNG Entropy source More QRNGs Added as demand grows SQP Sovereign Entropy High-availability appliance pair Node ANode B Continuous health testingHalts on any failed testSigned, nonce-bound seedsTamper-evident audit log HSM-protected ML-DSA identity Quantum-safe delivery TLS 1.3 + ML-KEM ML-DSA signed Virtual machines Seeds the kernel random number generator Kubernetes and containers One lightweight agent per node Serverless functions Reseeds after every snapshot restore HSMs and key vaults Seeding before high-value key generation Your workloads: any cloud, on-premises or edge Mixed with local entropy on arrival: seeds, never keys

Client-owned

The appliance pair runs in your racks, under your policies. No dependence on an outside randomness service.

Quantum-sourced

One or more quantum random number generators, with more added as demand grows.

Continuously verified

Every output is health-tested; the appliance stops automatically if anything looks wrong.

Seeds, never keys

Seeds are mixed with local entropy on arrival, so not even the appliance knows your final keys.

Every cloud

One root, one policy, one audit trail across every cloud

Lightweight, auditable agents bring the same quantum entropy root to AWS, Google Cloud, Azure, private cloud, edge and IoT, and seed your own HSMs.

Your premises or enclave SQP Sovereign Entropy One root of randomness you own One policy One audit trail One validation record Quantum RNG, scaled to demand PQC-secured TLS 1.3 + ML-KEM AWSEC2kernel RNG agentEKS / ECSDaemonSetLambdarestore hookGoogle CloudCompute EngineagentGKEDaemonSetCloud Runinit hookAzure and privateVM agentsAKSDaemonSetOn-prem serversKeys and devicesYour HSMsKey managersIoT provisioning

Every agent mixes delivered entropy with local sources. Applications keep using standard APIs: getrandom(), OpenSSL, Java SecureRandom and Python secrets.

When workloads ask for fresh entropy

First boot

Before host keys and first TLS sessions

Snapshot restore

So restored copies diverge

Scale-out

Every new instance, every time

Scheduled reseed

On the interval your policy sets

Before high-value keys

Long-lived and PQC key generation

Quantum-safe delivery

How a seed travels, step by step

The delivery path is treated with the same rigor as the quantum source.

Request

The agent presents its workload identity and a fresh nonce.

Secure channel

TLS 1.3 with hybrid ML-KEM (FIPS 203) and mutual authentication.

Quantum entropy

Health-tested, conditioned output from the quantum source.

Signed response

Bound to the nonce and a timestamp, signed with ML-DSA (FIPS 204) by an HSM-held key.

Verify

The agent rejects unsigned, stale or replayed responses.

Mix and seed

Mixed with local entropy to seed the kernel RNG or DRBG. Keys are made only inside the workload.

Challenge by challenge

How SQP Sovereign Entropy resolves each risk

ChallengeSQP Sovereign Entropy response
Weak or low-entropy seedsQuantum entropy, continuously health-tested to SP 800-90B and mixed with local sources in line with SP 800-90C. Seeds, never keys.
Early boot, cloning and restoreAgents request fresh entropy on boot, restore and scale-out, and before long-lived key generation, so copies diverge before creating secrets.
Opaque provider entropyA client-owned, auditable entropy root that supplements the provider's RNG; an attacker would need to defeat both.
Multi-cloud inconsistencyOne architecture, one policy and one audit trail across AWS, Google Cloud, Azure, private cloud and edge.
Harvest now, decrypt laterHybrid ML-KEM key exchange and ML-DSA-signed responses protect entropy in transit.
Replay or injected entropyNonce- and timestamp-bound, signed responses; mutual authentication of every workload.
Memory-safety flawsEntropy server written in Rust, in line with NSA and CISA guidance.
Audit and certificationFIPS 140-3 validated cryptographic module, SP 800-90B validation artifacts and full request logs for your auditors.
Dependence on a third partyYou own and operate the appliance; redundant units avoid any single point of failure.
Honest about scope

What it does not claim

Quantum entropy does not make a weak algorithm strong. It cannot repair keys already generated or copied inside a snapshot, libraries with their own poorly seeded generators, a compromised kernel, side-channel leakage or misconfigured access policies. Very early boot, before networking, still needs a sound local source. For provider-managed services, the leverage point is key generation in your own HSM.

If the appliance is unreachable, you decide

Continue with an alert

Workloads continue on validated local sources and raise an alert.

Block high-assurance keys

Designated high-assurance key generation waits until service returns.

Adoption path

From pilot to every cloud in five steps

  1. Baseline
    Inventory workloads, kernels, crypto libraries, snapshot mechanisms and key-generation points.
  2. Pilot
    One HA appliance pair with agents for Linux VMs and one Kubernetes cluster in one cloud.
  3. Lifecycle and failure tests
    Boot storms, cloning, snapshot and serverless restore, outages, replayed or malformed responses.
  4. Expand
    More clouds, HSM seeding, IoT provisioning and PQC key-generation workloads.
  5. Measure
    Time to RNG readiness, latency, availability, duplicate-output tests and cost against baseline.

Pilot one HA pair with one cluster

Design-partner places are available. Talk to us about a briefing or a pilot.

Contact salesBecome a design partner