I won’t dunk on the ColdCard guys because I know how hard it is to build a product, and a million things can go wrong, particularly with cryptography. I also know how terrible it feels as a user to suddenly lose money. But cryptographic security entirely depends on the keys being “random” aka hard-to-guess. You can have world class math on top of dollar-store randomness and it’s basically worthless if anyone realises what’s happening. If you have a cryptographic product, now would be a good time to audit your entropy sources. Here are some tips

Mix multiple sources Relying on a single source for entropy is risky. The source might not be as random as you think it is, either by accident or malice. Operating Systems (OSs) like macOS, Linux or Windows combine different sources such as - interrupt timings (driven by the timing of different hardware peripherals interacting) - hardware random number generators (RNGs) that use thermal or electrical noise as entropy - direct user input events (like mouse movements) Hardware wallets like Trezor typically don’t have much in the way of interrupt timings or user inputs so they tend to rely on hardware RNGs and possibly externally supplied entropy.

Mix it correctly When you mix sources of entropy you should use a secure hash function like SHA-512 or Keccak (there are many). These functions mix inputs very thoroughly: flipping one bit on the input on average changes half the bits of the output. This means that if even one of the inputs is very unpredictable, the output will be unpredictable. OS RNGs generally feed their inputs into a secure hash function and use the output as a seed for a cryptographically secure pseudo-random number generator (CSPRNG) like ChaCha or AES-CTR-DRBG to then generate an arbitrarily long series of random bytes.

Programmer Dos and Don’ts DO - use the OS CSPRNG - if you want to include user input, securely mix it with the OS entropy using a hash function (read how BIP39 works with passphrase) - use cryptographic libraries specifically made for this (libsodium, noble, bouncy castle, secrets) DON’T - use time as entropy - use the default random libraries in various languages (C, JS, Java, Python) - use environmental data (images, audio) alone as entropy

What ColdCard did wrong They had a hardware RNG that would have provided sufficient entropy but a subtle misconfiguration caused it not to be used, instead falling back to an insecure python default. Others have written this up in detail.

How an attacker would exploit If an attacker has to guess your 256 bit (secure) key and has no additional information, they have to search thru an impossibly big space of possibilities. Even computers have limits when the numbers are that big. That’s what makes it secure. If the attacker can narrow it down to, say 40 bits (the ColdCard worst case, about 1 trillion, 10 bits is about 1000 and adding bits multiplies possibilities), then this becomes feasible for a dedicated attacker who may be willing to throw a GPU farm at it given the size of the reward.

Summary Entropy / randomness is the most important part of a cryptographic system. Audit your sources of entropy as much as you audit the math on top. And Quantum Secure Your Crypto with Quantus