Fix #47: state that only hardware-backed entropy is genuinely random - #96
Open
corgab wants to merge 2 commits into
Open
Fix #47: state that only hardware-backed entropy is genuinely random#96corgab wants to merge 2 commits into
corgab wants to merge 2 commits into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
QuantumDevice::generateEntropy()was documented as producing a "cryptographically strong random bit-string" for every implementation, whilebin/python/entropy.pysays 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 useQuantum::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 shippedEntropyGeneratorcannot 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).EntropyGeneratorclass docblock: the same statement at the level users read most.random_bytes()for secrets meanwhile. The tagline no longer says "hardware-grade".config/aether.php: theawsdriver comment no longer claims "real quantum hardware" while the defaultdevice_arnis the SV1 simulator.bin/python/entropy.pymodule 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