Hi,
I would like to share an ongoing empirical study of a historical random-generation path relevant to Bitcoin 0.1.5 on Windows:
Windows XP SP3 CryptGenRandom
→ OpenSSL 0.9.8h
→ Bitcoin 0.1.5
This is not presented as a practical attack against Bitcoin, nor as a claim that historical private keys can be derived.
For clarity, this work is not intended to facilitate, encourage, or justify any attempt to compromise historical wallets, private keys, or funds; any such use would be contrary to the purpose and scope of this research. On the contrary, by making a historically relevant randomness path more explicit, testable, and reproducible, the work aims to strengthen the technical understanding of Bitcoin’s early software environment and to reduce uncertainty rather than create risk.
The work should therefore be understood as a risk-reduction and uncertainty-reduction effort around the Satoshi-era discussion. Its purpose is to replace vague assumptions about the old Windows/OpenSSL/Bitcoin randomness chain with a documented experimental decomposition: what is observed, what is replayed bit-exactly offline, what is strongly constrained by traces, and what remains open.
The study reconstructs and instruments part of the Windows XP CryptGenRandom path using WinDbg/KD traces, paired memory captures, controlled experiments, and offline Python replay.
CryptGenRandom is a real deployed cryptographic component, not a purely theoretical construction. One interesting next step is to measure the diffusion impact after the VLH stage and then after the ADVAPI/SystemFunction036 path involving the eight round-robin RC4 states. Other measurements would also be relevant, including edge-case questions discussed in the literature on weak keys and entropy failures, such as boot-time entropy holes. These should be treated carefully as limit-case analyses, not as immediate claims about historical Bitcoin key compromise.
Several parts of the pipeline are experimentally closed or replayed bit-for-bit in the captured runs, including:
* the kernel-side pool → VeryLargeHashUpdate → seedbase_after transformation;
* the final rsaenh block from observed state20 and aux20 to out40;
* the final copy of the first 32 bytes to the CryptGenRandom caller buffer;
* parts of the ADVAPI/SystemFunction036 path, including an observed RC4 round-robin segment replayed from captured RC4 states.
A recent campaign also captured a complete long path with VLH and provider/FIPS activity in the same run; it confirms clean state20 propagation on the rsaenh side, while keeping the upstream G transformation explicitly open.
The main remaining open point is the upstream provider-state mapping leading to state20. In particular, state20 is not observed as a direct 20-byte window copied from seedbase_after, which is consistent with G being a transformation rather than a simple copy.
I think this matters for historical Bitcoin analysis because early Bitcoin on Windows depended on OpenSSL, and OpenSSL on Windows could incorporate CryptGenRandom into its RAND state. This does not imply that CryptGenRandom was the only source, nor that RAND_bytes directly called CryptGenRandom each time. But it makes the Windows XP RNG path historically relevant and worth documenting precisely.
As stated in the acknowledgments of the pre-publication, I am solely responsible for this work, including its experiments, interpretations, limitations, and any possible errors.
Pre-publication:
https://cnrs.hal.science/hal-05611907Reproducibility artifacts:
https://github.com/Melik159/xp-cgr-replayThis does not alter Bitcoin’s protocol-level security; rather, it strengthens the historical analysis around early Bitcoin by reducing uncertainty about a real dependency in its early Windows software environment.
Technical comments, criticism, and independent review are welcome.
