Entropy, Randomness, and Quantum Security Services

Quantum systems are not only compute engines. They can also support security services: quantum random number generation, quantum-derived entropy, key-material workflows, and evidence-backed randomness services. These services require different operating disciplines than circuit execution.

A randomness service is a production security dependency. It must be monitored, validated, versioned, audited, and integrated into cryptographic systems without overclaiming what the quantum source proves. NIST SP 800-90B defines requirements and validation concepts for entropy sources used in random bit generation. NIST and its partners have also demonstrated public quantum-randomness beacons. Public beacon outputs serve public randomness applications; they must not be used as secret keys or as the sole secret entropy for key generation. A private key-material service needs a protected entropy source and a suitable cryptographic random-bit-generation construction. [R149]

Diagram loads as you read

Entropy, Randomness, and Quantum Security Services · Figure 1

View diagram source

flowchart LR
    QuantumSource[Quantum entropy source] --> Raw[Raw samples]
    Raw --> Health[Health tests]
    Health --> Extractor[Extractor]
    Extractor --> Conditioning[Conditioning]
    Conditioning --> API[Randomness API]
    API --> Consumers[Security consumers]
    Health --> Evidence[Evidence log]

Randomness is an operated service

A QRNG-style service has operational responsibilities:

define entropy source assumptions;
collect raw-source telemetry;
run startup and continuous health tests;
apply extractors and conditioners correctly;
record evidence for audits;
monitor throughput and latency;
fail closed when health is not established;
isolate consumers by tenant and purpose.

Diagram loads as you read

Randomness is an operated service · Figure 2

View diagram source

flowchart TB
    Service[Randomness service] --> Source[Source physics]
    Service --> Validation[Validation]
    Service --> API[API and delivery]
    Service --> Audit[Audit trail]
    Service --> Security[Security controls]
    Service --> Consumers[Consumer integration]

Entropy pipeline

Diagram loads as you read

Entropy pipeline · Figure 3

View diagram source

sequenceDiagram
    participant Device as Quantum source
    participant Collector
    participant Validator
    participant Extractor
    participant Vault as Entropy vault
    participant Client

    Device->>Collector: raw outcomes
    Collector->>Validator: batches with metadata
    Validator->>Validator: health and bias checks
    Validator->>Extractor: accepted batch
    Extractor->>Vault: conditioned entropy block
    Client->>Vault: request entropy
    Vault-->>Client: block + receipt

A production system should preserve enough metadata to re-evaluate historical claims without exposing secrets or raw material beyond policy limits.

Do not confuse properties

Diagram loads as you read

Do not confuse properties · Figure 4

View diagram source

flowchart TB
    Randomness[Randomness claims] --> Entropy[Entropy estimate]
    Randomness --> Unpredictability[Unpredictability]
    Randomness --> Independence[Independence]
    Randomness --> Certification[Certification]
    Randomness --> Delivery[Secure delivery]

A source can be physically quantum and still have implementation failures. A statistically strong sample can still be poorly delivered. A certified entropy source can still be misused downstream.

Claim	Evidence needed
source is operating within model	device telemetry and health tests
entropy estimate is valid	documented estimator and validation results
output is conditioned correctly	extractor version and configuration
delivered block matches its authenticated allocation	protected delivery, binding to tenant and request, and client-side verification; a server receipt alone does not prove receipt
material was not reused incorrectly	allocation ledger

Health states

Diagram loads as you read

Health states · Figure 5

View diagram source

stateDiagram-v2
    [*] --> ColdStart
    ColdStart --> Validating
    Validating --> Serving: tests pass
    Validating --> Quarantine: tests fail
    Serving --> Degraded: warning threshold
    Degraded --> Serving: recovery confirmed
    Degraded --> Quarantine: hard threshold
    Quarantine --> Validating: investigation complete

The service should not silently degrade. If the source model is not supported by current evidence, it should stop serving material that carries that claim.

API contract

Illustrative listing · yaml

randomness_request:
  tenant: payments-prod
  purpose: key_generation
  bytes: 4096
  min_entropy_claim: approved_profile_v3
  freshness_seconds_max: 300
  evidence_required: true

randomness_response:
  block_id: entropyblk_2026_04_19_001
  bytes: <redacted>
  source_profile: quantum_source_profile_v3
  extractor_version: extractor_2.4.1
  health_state: serving
  receipt_signature: <signature>

Diagram loads as you read

API contract · Figure 6

View diagram source

flowchart LR
    Request[Request] --> Policy[Purpose policy]
    Policy --> Allocation[Allocate block]
    Allocation --> Receipt[Issue receipt]
    Receipt --> Audit[Audit ledger]

Tenant isolation

Diagram loads as you read

Tenant isolation · Figure 7

View diagram source

flowchart TB
    Pool[Conditioned entropy pool] --> TenantA[Tenant A allocation]
    Pool --> TenantB[Tenant B allocation]
    Pool --> TenantC[Tenant C allocation]
    TenantA --> LedgerA[Allocation ledger A]
    TenantB --> LedgerB[Allocation ledger B]
    TenantC --> LedgerC[Allocation ledger C]

Never allow a shared pool to become a shared secret. Entropy allocation should be logged, non-overlapping, and scoped to purpose.

Evidence package

A randomness evidence package should include:

source profile;
device version;
physical operating envelope;
raw batch identifiers;
health-test results;
entropy-estimation method;
extractor version;
allocation record;
consumer receipt;
retention and deletion policy.

Diagram loads as you read

Evidence package · Figure 8

View diagram source

flowchart TB
    Evidence[Randomness evidence package] --> Source[Source profile]
    Evidence --> Tests[Health tests]
    Evidence --> Extractor[Extractor version]
    Evidence --> Allocation[Allocation ledger]
    Evidence --> Receipt[Signed receipt]
    Evidence --> Retention[Retention policy]

Failure modes

Diagram loads as you read

Failure modes · Figure 9

View diagram source

flowchart TB
    Failure[Failure modes] --> Bias[Source bias]
    Failure --> Drift[Source drift]
    Failure --> Extractor[Extractor misconfiguration]
    Failure --> Reuse[Block reuse]
    Failure --> Delivery[Delivery compromise]
    Failure --> Overclaim[Unjustified certification claim]

Mitigation requires both physics-aware tests and standard security engineering.

Operating rule

Quantum entropy is not magic. Treat it as a high-assurance data product with a physical source, a statistical claim, a conditioning pipeline, an API contract, and an audit trail.

Additional technical sources: [R266].