It is unfortunate to see people spreading AI-generated disinformation, especially the CEO of a Bitcoin security company. Posting unverified Claude output for attention, especially when you are trusted by so many people, I don’t know what to say.

This is the AI-generated misinformation I was referring to lol

Since apparently it is not simple enough: 🚨 If your *passphrase* was generated using the Coldcard, assume it is leaked. ⚠️ If you used microSD to store your passphrase, destroy the microSD, as it can be decrypted. ⚠️ If you used Coldcard Cosign and did not set your own seed, assume the privacy of your funds is rekt. ⚠️ If you split your seed with SeedXOR, only one part of it can be used to get the whole seed. (Most of the time) ⚠️ If you used the password generator on the Coldcard, consider the generated passwords compromised. ✅ If you previously used HSM mode, that is fine. Stop using it, though. ✅ Key teleport is safe. ✅ If your seed was generated with dice, it is safe.

Ugh. Not AI slop :(

Should be fine as it uses a standard algorithm

I wouldn’t rely on it

1. About as secure as the passphrase. So, somewhat harder than a brain wallet to crack. (Unless you used truly random words) 2. Yes. You can just add more rolls anyway

The obscurity of this issue specifically is almost the level of Jia Tan inserting a dot to break the sandboxing enable defined in CMakeLists.txt in xz.

On Twitter, there is some AI-generated misinformation going around about the safety of dice-generated seeds. Only in the following cases are your seeds NOT SAFE: 🚨 You generated your seed with the Coldcard. 🚨 You used the Password Generator to generate a passphrase, along with a CC-seed. In the following cases, your funds are SAFE, but you need caution: ⚠️ SeedXOR: If you used the TRNG option, only one of your shards may be enough to recover the seed. However, they must find the specific shard. ⚠️ MicroSD 2FA: The passphrase stored on the SD card can be decrypted. If you destroy it, you’re fine. ⚠️ Cosign: If you used a CC-generated key, the co-sign can be bypassed + your privacy gone. Otherwise, 0 risk. ⚠️ Password generator: Passwords generated by it are not safe. Rotate them, but this has no impact on your funds. In the following cases, your funds are SAFE: ✅ HSM mode: The weak RNG was used, but does not have any impact on fund safety. ✅ Key Teleport: The weak RNG-generated password was used on top of ECDH, which nullifies risks. ✅ Dice generation: This uses a standard algorithm.

Well, asking it for opinions is completely different than using it as a tool *with proper knowledge* to find issues.

It is weird to see that people trust AI to evaluate the security of whatever HWW they use. These models cannot form independent opinion, and only repeat what people already said. From my testing, they get an egregious number of things extremely wrong. But I guess these models are trained to *sound* like an expert in everything, so…

gm nostr

If you are disposing of your Coldcard, please take extra measures to overwrite the seed and PIN before disposing of it.

What do people actually think the benefits of a Bitcoin-only edition of an HWW are?!

I have pushed an update to Damus Translate which should increase the quality of nuanced translations and reduce some false positives

Maybe it would be beneficial to have a series of blog posts demystifying hardware wallets and Bitcoin security.

And, after this incident, what will change? All of this will still happen: ✅ Usage of i chips ✅ Basically no code review except once-in-a-while audits ✅ Firmware development done by people with no cryptography experience and the list goes on The founders of these companies are so disconnected from the risks of their products

It is unfortunate to see that so much great Nostr stuff has been consumed by the AI slop virus

It seems that the details were already posted all over the place over Twitter and Telegram, so here is an explanation of it: In Coldcard, there are two implementations of getting bytes from the HWRNG, in cckt and libngu. The path in libngu is used for generating seeds. This one calls the MicroPython API to get random values. The MicroPython API uses the HWRNG if enabled. The problem was that Coinkite disabled the HWRNG for MicroPython. This should not have been an issue, as libngu had a check to see if the HW RNG is enabled. However, this used ifndef, which explicitly checked *if the HW RNG enable was not configured*. It did not check if the HW RNG enable was turned off explicitly, which is what Coinkite did. This led to their code using the flawed software MicroPython RNG, which was solely based on the device boot time and a very weak manufacturing identifier. This means that there are not a lot of different seeds. In Mk4/Mk5, this issue still exists. The only difference is that 32 actually random bits (which is tiny) have been mixed into the RNG. By overly complicating their codebase, in what can only be described as “attempted security through complexity”, they have put all user funds at risk. Regarding the implications: - If you generated using dice or wordlist or another method that included non-Coldcard entropy, you are fine. - If you generated on a non-Coldcard device, you are fine. - If not, your funds are at risk. A passphrase will help slow it down but the main seed is still compromised. Multisigs: You are affected *privacy wise* if one of your members is a Coldcard-generated seed. You are only at risk if the majority of your members are CC. Secure element RNGs: These are fine. You need a proper one though from Infineon/NXP/ST, and not the crappy IoT ones. Also beware the HWW firmware can still butcher the resulting numbers.