Skip to content

Fix #47: state that only hardware-backed entropy is genuinely random - #96

Open
corgab wants to merge 2 commits into
mainfrom
fix/47-entropy-strength-docs
Open

Fix #47: state that only hardware-backed entropy is genuinely random#96
corgab wants to merge 2 commits into
mainfrom
fix/47-entropy-strength-docs

Conversation

@corgab

@corgab corgab commented Sep 8, 2026

Copy link
Copy Markdown
Owner

Summary

QuantumDevice::generateEntropy() was documented as producing a "cryptographically strong random bit-string" for every implementation, while bin/python/entropy.py says the opposite for the local simulator: its bits come from a classical pseudorandom simulation of the circuit. A reader of the PHP contract could reasonably use Quantum::entropy('local') for keys or tokens. The same caveat applies to the managed Braket simulators (SV1 and friends), and there is a further constraint the docs never stated: entropy generation is synchronous, and synchronous runs against a QPU are refused by the synchronous-safety rules, so as shipped EntropyGenerator cannot reach real hardware at all.

Plan

Say the same thing everywhere a reader might look, in the contract, the generator, the README, the config comments, the Python module and the project conventions: only hardware measures genuinely random bits, every simulator is pseudorandom, and today the generator only reaches simulators, so secrets should come from the platform CSPRNG until an asynchronous entropy path exists.

Changes

  • QuantumDevice::generateEntropy() docblock: states the rule at contract altitude for any implementation (implementations must not present simulated bits as hardware entropy; callers must rely only on hardware-backed implementations for secrets).
  • EntropyGenerator class docblock: the same statement at the level users read most.
  • README "Entropy Generation": a call-out explaining where the randomness comes from, which backends are pseudorandom, why the generator cannot currently target a QPU, and to use random_bytes() for secrets meanwhile. The tagline no longer says "hardware-grade".
  • config/aether.php: the aws driver comment no longer claims "real quantum hardware" while the default device_arn is the SV1 simulator.
  • bin/python/entropy.py module docstring: leads with the hardware case and covers the managed simulators.
  • CLAUDE.md: one conventions bullet so docblocks never call simulator entropy cryptographically strong again.

Documentation only: no runtime, config value or dependency change, so there is no test to turn from red to green; the full PHP and Python suites still pass.

Tests

Local: pint passed, pest 791 tests passed, pytest 51 passed.

Closes #47

The QuantumDevice contract promised cryptographically strong entropy for
every driver, while entropy.py itself describes the local simulator's bits
as pseudorandom. The contract, the EntropyGenerator class docblock, the
README entropy section, the Python module docstring and CLAUDE.md now say
the same thing: a QPU measures genuinely random bits, the local and managed
simulators draw them from a classical pseudorandom generator, and only
hardware-backed entropy belongs in keys, tokens and nonces.

Closes #47
… yet

Entropy generation is synchronous and synchronous runs against a QPU are
refused, so EntropyGenerator can only reach simulators today; the README
now says to treat its output as pseudorandom and to use the platform CSPRNG
for secrets. The Python docstring leads with the hardware case instead of
an unqualified "quantum in origin", the aws driver comment in config no
longer claims real hardware while defaulting to SV1, and the contract
states the rule for any implementation rather than for the two built-in
drivers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[contracts] QuantumDevice::generateEntropy() docblock claims "cryptographically strong" for all drivers, contradicting the local simulator

1 participant