Predictable RNG fallback and 32-bit reseed
block-disclosure
https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
- Organisation
- Block
- Evidence role
- Primary technical research
- Published
- 2026-07-30
- Source changes
- 0
- Detected differences
- 0
- Unreviewed
- 0
- Copies held
- 2
Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked 2 Aug 2026, 00:58 UTC.
Public privacy boundary
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain victim addresses. Integrity hashes, capture times and reviewed change summaries remain available below.
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
$ cd ~ $ find . ~/posts/predictable-rng-fallback-and-32-bit-reseed-in... $ cd .. Engineering July 30, 2026 Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware How a deterministic fallback and limited secure-element reseed constrain entropy across COLDCARD generations $ git blame Square Engineering The official account for @Square Engineering. $ cat content.md By Block Bitcoin Engineering and Security, in collaboration with anonymous security researchers. Summary Following reports from COLDCARD users, and working alongside other security researchers, Block’s Bitcoin Engineering and Security teams root-caused vulnerabilities that allow for theft of Bitcoin from COLDCARD users. This analysis is based on our current understanding of the situation. We have not done full empirical testing to confirm exploitability. We are publishing this advisory early, because active exploitation is under way. This analysis is the opinion of Block, and based on our internal research; we recommend looking at Coinkite's definitive report once available. This report does not pertain to Block products; no Block products or customers are affected by this vulnerability. COLDCARD firmware contains an RNG integration error that causes ngu.random to use MicroPython's deterministic Yasmarang fallback instead of the STM32 hardware RNG. The production board configuration defines MICROPY_HW_ENABLE_RNG as zero because COLDCARD provides a separate hardware-RNG wrapper. Libngu incorrectly checks whether that macro is defined rather than whether it is enabled. The build therefore succeeds, and libngu binds to MicroPython's rng_get(). With the macro set to zero, that function is a Yasmarang software generator initialized from the MCU UID and timer registers. The consequences differ by device: Mk2/Mk3 v4: No cryptographic entropy is added to ngu.random. For a known UID, timer state and call history, wallet generation is deterministic. Mk4/Q/Mk5: Boot adds secure-element entropy, but hashes it and retains only four bytes. reseed() then replaces only one 32-bit Yasmarang state word. For a fixed fallback state and call history, there are at most 2^32 securely distinguished output streams. Wallet generation hashes the resulting 32 bytes, but deterministic hashing cannot increase the number of possible seeds. Affected products DeviceFirmware used when generating the secretAssessment Mk1All released firmware through v3.0.6Outside this regression Mk2Through v3.2.2Uses the direct STM32 hardware RNG Mk2v4.0.0–v4.1.9Confirmed vulnerable path; no secure reseed Mk3Through v3.2.2Uses the direct STM32 hardware RNG Mk3v4.0.0–v4.1.9Confirmed vulnerable path; no secure reseed Mk4Production v5.0.0 onwardFallback remains; secure reseed is limited to 32 bits QAll production firmwareSame Mk4 fallback and reseed construction Mk5All production firmwareSame current Mk firmware construction Exposure depends on the firmware used when a secret was generated, not the device's manufacturing date. Upgrading does not retroactively weaken or repair an existing seed. Impact An attacker who can determine or sufficiently constrain the device UID, timer state and RNG-call history can reproduce the fallback stream offline. A wallet xpub, address or generated public key provides a candidate-validation oracle. Successful recovery of a wallet seed or private key permits theft of all associated funds. For Mk2/Mk3 v4, there is no cryptographically generated secret input to enumerate. For current devices, once the fallback state and call history are fixed, the remaining secure-element-derived search space is at most 2^32, averaging approximately 2^31 candidate trials. This does not mean every remote attacker can immediately recover every seed. Practical cost depends on available UID information, boot timing, prior RNG calls and derivation cost. No end-to-end brute-force benchmark is claimed here. Impact due to seed export If you exported a seed generated in a vulnerable coldcard, moving it to another wallet, then that same insecure seed is still affected.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
$ cd ~ $ find . ~/posts/predictable-rng-fallback-and-32-bit-reseed-in... $ cd .. Engineering July 30, 2026 Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware How a deterministic fallback and limited secure-element reseed constrain entropy across COLDCARD generations $ git blame Square Engineering The official account for @Square Engineering. $ cat content.md By Block Bitcoin Engineering and Security, in collaboration with anonymous security researchers. Summary Following reports from COLDCARD users, and working alongside other security researchers, Block’s Bitcoin Engineering and Security teams root-caused vulnerabilities that allow for theft of Bitcoin from COLDCARD users. This analysis is based on our current understanding of the situation. We have not done full empirical testing to confirm exploitability. We are publishing this advisory early, because active exploitation is under way. This analysis is the opinion of Block, and based on our internal research; we recommend looking at Coinkite's definitive report once available. This report does not pertain to Block products; no Block products or customers are affected by this vulnerability. COLDCARD firmware contains an RNG integration error that causes ngu.random to use MicroPython's deterministic Yasmarang fallback instead of the STM32 hardware RNG. The production board configuration defines MICROPY_HW_ENABLE_RNG as zero because COLDCARD provides a separate hardware-RNG wrapper. Libngu incorrectly checks whether that macro is defined rather than whether it is enabled. The build therefore succeeds, and libngu binds to MicroPython's rng_get(). With the macro set to zero, that function is a Yasmarang software generator initialized from the MCU UID and timer registers. The consequences differ by device: Mk2/Mk3 v4: No cryptographic entropy is added to ngu.random. For a known UID, timer state and call history, wallet generation is deterministic. Mk4/Q/Mk5: Boot adds secure-element entropy, but hashes it and retains only four bytes. reseed() then replaces only one 32-bit Yasmarang state word. For a fixed fallback state and call history, there are at most 2^32 securely distinguished output streams. Wallet generation hashes the resulting 32 bytes, but deterministic hashing cannot increase the number of possible seeds. Affected products DeviceFirmware used when generating the secretAssessment Mk1All released firmware through v3.0.6Outside this regression Mk2Through v3.2.2Uses the direct STM32 hardware RNG Mk2v4.0.0–v4.1.9Confirmed vulnerable path; no secure reseed Mk3Through v3.2.2Uses the direct STM32 hardware RNG Mk3v4.0.0–v4.1.9Confirmed vulnerable path; no secure reseed Mk4Production v5.0.0 onwardFallback remains; secure reseed is limited to 32 bits QAll production firmwareSame Mk4 fallback and reseed construction Mk5All production firmwareSame current Mk firmware construction Exposure depends on the firmware used when a secret was generated, not the device's manufacturing date. Upgrading does not retroactively weaken or repair an existing seed. Impact An attacker who can determine or sufficiently constrain the device UID, timer state and RNG-call history can reproduce the fallback stream offline. A wallet xpub, address or generated public key provides a candidate-validation oracle. Successful recovery of a wallet seed or private key permits theft of all associated funds. For Mk2/Mk3 v4, there is no cryptographically generated secret input to enumerate. For current devices, once the fallback state and call history are fixed, the remaining secure-element-derived search space is at most 2^32, averaging approximately 2^31 candidate trials. This does not mean every remote attacker can immediately recover every seed. Practical cost depends on available UID information, boot timing, prior RNG calls and derivation cost. No end-to-end brute-force benchmark is claimed here. Impact due to seed export If you exported a seed generated in a vulnerable coldcard, moving it to another wallet, then that same insecure seed is still affected.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
How to check this yourself
Each copy above is identified by the SHA-256 of its extracted text, shown beside it, and the diffs are plain unified diffs. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.
Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.
How to check this yourself
The SHA-256 prefixes above identify each held copy without turning this page into a mirror of somebody else's post. Compare a quotation against the original. If the post has since been edited or deleted, ask and the held copy can be produced.