A controlled experimental framework for investigating whether sustained CPU load is associated with observable changes in the output characteristics and acquisition performance of Python's secrets.token_bytes().
The experiment combines a paired AB/BA design, sustained CPU stress, positive controls with known statistical bias, raw-data preservation, system-level monitoring, and statistical analysis with confidence intervals, permutation tests, non-parametric tests, and false-discovery-rate correction.
Important: This project does not attempt to prove cryptographic security or provide a cryptographic proof of the security of
secrets.token_bytes(). It evaluates experimentally observable statistical and performance characteristics under the tested operating conditions.
Does sustained CPU load produce measurable changes in the observable statistical properties or acquisition performance of bytes generated by Python's secrets.token_bytes()?
The study focuses on experimentally testable properties rather than making claims about the internal cryptographic security of the operating system's random-number generator.
The experiment uses a balanced paired design:
- 30 paired experiments
- 15 AB pairs: idle → stress
- 15 BA pairs: stress → idle
- 5,000,000 bits per session
- 30 seconds of sustained CPU stress
- 60-second cooldown between paired conditions
- System monitoring at 200 ms intervals
- Raw byte preservation with SHA-256 integrity hashes
- Repeated positive-control experiments with deliberately biased generators
Each normal experimental pair therefore contains one idle session and one CPU-stressed session generated under the same pair identifier.
The AB/BA ordering is randomized to reduce potential systematic effects caused by temporal ordering.
The main endpoints are:
- Proportion of ones
- Random-byte generation latency
- Generation throughput
The proportion of ones is used as a direct observable measure of the balance between binary outcomes.
Latency and throughput are evaluated separately because CPU load may affect acquisition performance even when the statistical distribution of the generated output remains stable.
The framework additionally records:
- CPU utilization during generation
- CPU temperature
- CPU frequency
- Average CPU utilization
- Average CPU temperature
- Average CPU frequency
- System memory utilization
- Linux kernel entropy availability, where available
- CPU frequency governor
- Possible thermal throttling
- Generation time
- Generation throughput
These measurements allow potential system-level confounders to be examined alongside the primary endpoints.
The generated data are also subjected to several descriptive statistical diagnostics:
- Monobit frequency test
- Runs test
- Block-frequency test
- Byte-level chi-square test
- Lag-1 autocorrelation
- Cumulative-sums diagnostic
- Longest-run diagnostic
- Serial-pattern diagnostic
- Approximate-entropy diagnostic
These diagnostics are treated as descriptive evidence, rather than as independent proof of cryptographic security.
Passing statistical randomness tests should not be interpreted as demonstrating cryptographic security.
The experiment includes deliberately biased random generators with target probabilities:
p = 0.51p = 0.505p = 0.5005
These positive controls provide an important validation step.
If the statistical pipeline is functioning correctly, it should be capable of detecting sufficiently large artificial deviations from an unbiased Bernoulli process.
This distinguishes:
"The experiment did not detect an effect"
from
"The experiment was incapable of detecting an effect."
The paired experimental structure is preserved during analysis.
For each endpoint, the framework calculates:
- Paired mean difference
- 95% confidence interval
- Paired Student's t-test
- Wilcoxon signed-rank test
- Paired permutation test
- Cohen's d for paired differences
- Shapiro-Wilk normality diagnostic
False-discovery-rate correction using the Benjamini-Hochberg procedure is applied to the predefined primary and secondary endpoint family.
A sensitivity analysis is also performed to estimate statistical power across a range of standardized effect sizes.
The experiment preserves the generated raw byte streams and records a SHA-256 hash for each dataset.
Each session records:
- Experimental condition
- Pair identifier
- Experimental order
- Timestamp
- Number of generated bits and bytes
- Raw-data file
- SHA-256 hash
- System measurements
- Generator latency
- Throughput
- Statistical diagnostics
The experiment also exports machine-readable JSON and CSV datasets together with Markdown and LaTeX reports.
The central interpretation is deliberately conservative.
If no statistically detectable difference is observed between idle and CPU-stressed conditions, this provides evidence that no measurable change was detected within the tested experimental design, sample size, hardware, operating system, and workload conditions.
It does not establish that:
- CPU load can never affect a CSPRNG;
- the underlying entropy source is unaffected;
- the operating system RNG is cryptographically secure because of this experiment;
- all hardware or software configurations would produce the same result;
- absence of statistical evidence is proof of equivalence.
The appropriate scientific conclusion is therefore one of empirical non-detection under specified conditions, not proof of universal invariance.
The experiment is designed to answer questions such as:
- Is there an observable shift in the proportion of generated ones?
- Does CPU stress measurably affect generation latency?
- Does CPU stress measurably affect throughput?
- Are system-level variables associated with observed differences?
- Can the analysis pipeline detect deliberately introduced statistical bias?
- Are any observed effects consistent across paired experimental conditions?
This project is not a cryptographic audit.
It cannot independently establish:
- the security of the underlying kernel CSPRNG;
- the unpredictability of future outputs;
- resistance against adversarial observation;
- entropy quality at the hardware level;
- absence of implementation vulnerabilities;
- cryptographic equivalence across operating systems.
Cryptographic security requires substantially different forms of analysis, including examination of the underlying RNG architecture, entropy collection, state management, reseeding behavior, implementation, and threat model.
CSPRNG-Load-Stability/
│
├── experiment.py
├── README.md
├── fingerprint_experiment_v7/
│ ├── sessions.csv
│ ├── experiment.json
│ ├── report.md
│ ├── report.tex
│ └── *.bin
│
└── ...
The exact filenames may vary depending on the implementation and execution environment.
Python 3.x with:
- NumPy
- SciPy
- psutil
- statsmodels
- matplotlib
- tkinter
Install the Python dependencies with:
pip install numpy scipy psutil statsmodels matplotlibRun:
python experiment.pyThe graphical interface allows the experiment to be started, monitored, and reported.
Generated datasets and reports are stored in:
fingerprint_experiment_v7/
The experiment records the relevant configuration and system metadata, including:
- CPU model
- CPU count
- RAM
- Python version
- NumPy version
- SciPy version
- psutil version
- CPU governor where available
- Thermal-throttling status where available
- Experimental parameters
The positive controls use deterministic seeds to make their artificial bias reproducible.
The normal secrets.token_bytes() condition intentionally relies on the operating system's cryptographically secure random source.
This project should be understood as an empirical systems-and-statistics study of observable CSPRNG behavior under computational stress, rather than as a proof of cryptographic security.
Its value lies in the controlled experimental methodology:
paired conditions + randomized order + positive controls + raw-data preservation + system telemetry + statistical analysis + conservative interpretation.
This work sits at the intersection of:
- Computer Security
- Applied Cryptography
- Operating Systems
- Random Number Generation
- Statistical Testing
- Systems Performance
- Experimental Computer Science
It may be particularly relevant to research involving CSPRNG behavior, operating-system entropy sources, system-load effects, and empirical evaluation of random-number generation systems.
Add the license appropriate for your intended use and publication status.