Cryptographic systems often fail in places that users never see.

A product may use strong algorithms. It may store keys in secure hardware. It may be disconnected from the Internet. Its source code may be publicly available for review. Yet none of those protections matter if the secret keys protecting the system are generated from predictable inputs.

The ongoing attack against Coldcard Bitcoin hardware wallets provides a costly demonstration of that principle.

Bloomberg reported on August 3, 2026, that attackers had drained approximately 1,367 Bitcoin—worth roughly $86 million at the time—from more than 4,500 wallets. The attackers reportedly did not need to compromise the physical devices, steal backup phrases, install malware, or break Bitcoin’s elliptic-curve cryptography. Instead, they appear to have exploited predictability in the process used to generate wallet seeds. not primarily a failure of Bitcoin.

It was a failure of entropy.

What Happened to the Coldcard Wallets?

A Bitcoin hardware wallet protects its assets through private keys derived from a wallet seed. That seed must be selected from an enormous and unpredictable set of possible values.

When seed generation works correctly, searching the possible seed space is computationally infeasible. An attacker cannot simply guess the seed, even with substantial computing resources.

According to an analysis published by Block’s Bitcoin Engineering and Security team, certain Coldcard firmware versions contained an integration error that caused wallet generation to use MicroPython’s deterministic Yasmarang software generator rather than the intended STM32 hardware random-number generator. The software fallback was initialized using information including the microcontroller’s unique identifier and timer state. ’s technical explanation describes the problem as an integration failure introduced during a 2021 migration. Wallet seed generation moved from a device-specific random-number function to a library interface that ultimately resolved to the wrong implementation of rng_get(). Both implementations exposed the expected function signature, so the software compiled successfully even though seed generation reached the deterministic fallback instead of the intended hardware entropy path. tinction is critical.

The device reportedly contained hardware capable of generating randomness. The intended entropy implementation was even present in the firmware binary. But the security-sensitive operation did not reliably use it.

The presence of a good entropy source does not protect a system when the key-generation path bypasses that source.

Offline Keys Are Not Necessarily Unpredictable Keys

Hardware wallets are frequently described as “cold storage” because their private keys are isolated from Internet-connected computers.

That isolation provides meaningful protection against remote malware, credential theft, and many classes of online attack. But it does not correct a weak key-generation process.

An offline device can still generate a predictable key.

Once an attacker can reconstruct the possible outputs of a defective random-number generator, the attack can be performed offline. Candidate seeds can be generated, corresponding Bitcoin addresses can be derived, and those addresses can be compared with the public blockchain.

The attacker does not need to communicate with the wallet. The blockchain itself reveals which candidate keys control funded addresses.

Reports associated with the investigation described multiple waves that swept approximately 1,367 Bitcoin from 4,585 addresses. The initial wave reportedly drained 1,083 Bitcoin from 1,196 addresses in only 41 minutes. ck illustrates an uncomfortable reality:

Physical isolation protects a secret from extraction. It does not make a poorly generated secret more difficult to predict.

Entropy Determines the Real Strength of a Key

Cryptographic keys are often described by their nominal size: 128 bits, 256 bits, or another algorithm-specific value.

However, a 256-bit field does not automatically provide 256 bits of security.

If a 256-bit key is generated from a process containing only 40 bits of uncertainty, an attacker does not need to search all (2^{256}) possible keys. The attacker only needs to search the much smaller set of values the defective generator could realistically produce.

Coinkite offered preliminary estimates of approximately 40 bits of effective search space for affected Mk2 and Mk3 devices and approximately 72 bits for later models that mixed in additional secure-element data. Coinkite cautioned that these estimates were preliminary, while Block published a separate and, in some scenarios, more pessimistic analysis of the reachable output space. The precise attack cost therefore remains under technical review. der conclusion does not depend on which estimate ultimately proves most accurate.

The generated seeds did not consistently provide their intended security strength.

This is why entropy assessments focus on unpredictability rather than merely counting the number of output bits. Hashing, formatting, or expanding a weak input into a longer value does not manufacture additional entropy. A deterministic function can redistribute existing uncertainty, but it cannot create uncertainty that was never present.

Strong Cryptography Cannot Repair Weak Randomness

The Coldcard incident is another reminder that strong algorithms cannot compensate for predictable key generation.

Bitcoin uses well-studied cryptographic primitives. The affected implementation migrated elliptic-curve operations to libsecp256k1, the implementation used by Bitcoin Core. Coinkite described that cryptographic choice as sound; the failure occurred in the surrounding integration and randomness path. tinction matters far beyond cryptocurrency.

Weak entropy can undermine:

  • TLS server keys and certificates

  • SSH host and user keys

  • Code-signing keys

  • Firmware-signing keys

  • Authentication tokens

  • Session identifiers

  • API secrets

  • Disk-encryption keys

  • VPN and IPsec key establishment

  • Cloud key-management systems

  • Post-quantum cryptographic keys

An attacker does not need to break AES, RSA, elliptic-curve cryptography, or a post-quantum algorithm when the implementation chooses keys from a predictable subset.

In that situation, the attacker attacks the key-generation process instead of the algorithm.

Good Entropy Requires More Than an RNG Component

A secure random-bit generation design is a pipeline.

It normally includes a physical or environmental noise source, digitization, optional conditioning, health testing, entropy estimation, a deterministic random bit generator, and the application code that requests cryptographic output.

Every part of that path matters.

The Coldcard failure demonstrates why engineers must verify questions such as:

  1. Which implementation is actually linked into the production build?

  2. Which function does the application call when generating a key?

  3. Can compilation options silently select a deterministic fallback?

  4. Does the fallback fail closed or continue producing plausible-looking output?

  5. Is fresh entropy incorporated at the intended times?

  6. Are errors from the entropy source propagated to the caller?

  7. Do tests exercise the final production binary and configuration?

  8. Can generated secrets be traced back to the expected entropy source?

Random output can look convincing while being completely predictable. Ordinary statistical tests performed only on final output may not detect a deterministic generator with a sufficiently uniform distribution.

Entropy assurance therefore requires architectural analysis, source characterization, health testing, and end-to-end verification—not simply checking that output “looks random.”

What NIST’s Random-Bit Generation Framework Gets Right

The NIST SP 800-90 series separates random-bit generation into distinct components:

  • SP 800-90A specifies deterministic random bit generator mechanisms.

  • SP 800-90B defines requirements and validation methods for entropy sources.

  • SP 800-90C defines complete random bit generator constructions combining entropy sources and DRBG mechanisms.

NIST finalized SP 800-90C in September 2025, completing a framework that explicitly distinguishes the entropy source from the deterministic mechanism that expands entropy into usable random bits. 0B addresses the design, analysis, testing, and validation of entropy sources rather than assuming that a component labeled “TRNG” is automatically trustworthy. aration is important because a DRBG can be cryptographically excellent and still produce predictable output when it is initialized with insufficient entropy. Likewise, a high-quality physical noise source is ineffective when integration errors prevent its output from reaching the DRBG.

The entire construction must be evaluated.

Validation Must Follow the Actual Production Path

The incident also highlights the value—and limitations—of cryptographic validation.

FIPS 140-3 and the Cryptographic Module Validation Program require vendors to document and justify entropy used in cryptographic module operations. Since November 2020, applicable FIPS module submissions have been required to provide documentation supporting conformance with SP 800-90B. quirements create valuable pressure to:

  • Identify the noise source.

  • Quantify the entropy it produces.

  • Document conditioning and health tests.

  • Describe how the DRBG is seeded.

  • Test the implementation in its operational environment.

  • Establish the security strength of generated keys and other sensitive parameters.

Validation, however, must examine the implementation that is actually shipped.

Reviewing the intended hardware RNG is insufficient when the production linker selects another function. Testing a source file in isolation is insufficient when build flags change symbol resolution. Evaluating a development configuration is insufficient when production optimizations or dependencies change the call path.

The lesson is not merely “use a validated RNG.”

The lesson is to validate the complete, production-equivalent entropy and random-bit generation construction from the noise source to the generated key.

Entropy Failures Must Fail Closed

One of the most dangerous characteristics of randomness failures is that the system may continue operating normally.

The device still generates a seed phrase. The words look random. The wallet creates valid addresses. Transactions work. The defect may remain invisible until an attacker searches the reduced key space.

Security-sensitive systems should therefore fail closed when the expected entropy source is unavailable or incorrectly configured.

A build should fail when the required RNG implementation is missing. Startup testing should detect unavailable or unhealthy entropy sources. Key generation should return an error rather than silently switching to an unapproved deterministic fallback.

Coinkite reports that its hotfix now excludes the fallback object and adds a build-time symbol check intended to ensure that the board-specific implementation supplies the expected RNG function. the correct design philosophy: an obvious failure during development is far safer than a plausible-looking secret generated without adequate entropy.

Updating Software Does Not Repair an Existing Weak Key

An important operational lesson from the incident is that correcting the random-number generator does not strengthen keys that were already generated.

Coinkite has released fixed firmware for affected product lines, but its advisory states that installing the update does not repair an existing seed. Unless an identified exception applies, affected users must generate a completely new seed using corrected firmware and migrate their funds to addresses controlled by the new seed. principle applies to other cryptographic systems.

After an entropy failure:

  • Existing keys should be treated as potentially compromised.

  • New keys must be generated from a corrected and verified construction.

  • Certificates and associated credentials may need to be reissued.

  • Trust stores and public-key records may need to be updated.

  • Data protected only by the old keys may require additional analysis.

  • Merely copying the old key to a secure device does not remove its original weakness.

Key provenance matters. A key generated with insufficient entropy remains weak regardless of where it is later stored.

The Real Lesson of the Coldcard Attack

The Coldcard attack should not be reduced to a story about one hardware wallet manufacturer or one software bug.

It demonstrates a universal truth about cryptographic engineering:

Cryptography is only as strong as the process that creates and manages its secrets.

Secure hardware cannot compensate for predictable seeds. Offline storage cannot compensate for weak key generation. A trusted cryptographic library cannot compensate for an incorrect integration path. Open source cannot compensate for incomplete review. Long keys cannot compensate for low entropy.

Organizations building cryptographic products should be able to demonstrate—not merely assume—that:

  • Their entropy source produces sufficient unpredictability.

  • Their production software actually reaches that source.

  • Their DRBG is seeded and reseeded correctly.

  • Entropy failures cannot silently fall back to predictable behavior.

  • Their tests examine production-equivalent binaries.

  • Their security claims are independently validated where appropriate.

The attackers in this incident did not need to defeat Bitcoin’s strongest cryptography.

They reportedly found a way around it.

That is what makes entropy failures so dangerous—and why good entropy must be treated as a foundational security requirement rather than an implementation detail.