pull down to refresh

Out of an abundance of caution, Coinkite is warning all users who generated a seed using a Mk3 on version 4.0.1 (March 2021) or any subsequent version that their funds may be at risk.

Mk4, Q and Mk5 are not affected based on our early analysis of the issue.

The issue is present through https://coldcard.com/downloads/all, the final release that supported Mk3.

For more context see #1536238

mk4s are club but millions of times harder

src

reply

workin' on it, workin' on it :grimace:

reply

*vuln

reply

that’s for club? I interpreted that to mean bricked, or useless haha same effect

reply
reply
1055 sats \ 1 reply \ @Kruw 31 Jul

Sorry @k00b but I'm nuking this duplicate with a downzap: Other models are affected as well, so we don't want anyone to get the wrong information.

I just helped someone who almost left their coins vulnerable: https://x.com/Birch2124/status/2083014108618633220

reply

fixed it: #1536720

reply

Block's security team posted a blog on their analysis of the exploit.
https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware

reply

mfing macros

they used

#ifndef MICROPY_HW_ENABLE_RNG

when they meant

#if MICROPY_HW_ENABLE_RNG == 0
reply

I never got far enough into C to learn about ifndef. It seems like a fairly different thing than a boolean comparison. You think someone brain farted, or an accidental fat finger?

reply

Brainfart. C macros are notoriously inscrutable. It's a really easy mistake to make and macros make the error really easy to miss and mistest. No one, and I'm sure others have audited the code, saw this until now.

I like macros, but mostly because I like inscrutable things sometimes.

reply

Great report!

reply

And also, oh boy:

source

reply

what's the point of posting an unreadable screenshot and saying "confirmed vuln"? what's the vuln?

reply

afaik

  1. guaranteed entropy bug in mk3 with its available firmware
  2. entropy bug could be in mk4 also running the old firmware (it shipped before the bug was fixed according to NVK's version range)
  3. without more info, worth assuming entropy bug could be in all coldcard devices with any firmware
reply

I'm more just wondering what that screenshot is supposed to say. It looks like a diff but can't read any of it.

reply

afaict it's LLM output showing that the LLM recovered the seed from the xpub.

reply
974 sats \ 1 reply \ @Murch 31 Jul

Right. Instagibbs was able to regenerate an affected wallet’s seed by using a firmware-reset Coincard. The only necessary input was the number of button pushes on the device. I have seen someone state that the wallets were generated just with 17 bits of entropy and maybe the date, which is trivial to traverse programmatically.

reply

that's actually crazy

reply

This is a very very massive hack. But of course the stackers know that.
My guess is that the 'real' hacking is just beginning.

A low-entropy passphrase is not good enough because a '25th word' is a joke to brute force it's basically like not even having one. And a lot of people won't know about the hack, and now that the whole world is looking for it all the those seed phrases are toast. Next the hackers will be using low-entropy '25th words' with low-entropy seeds just GPUs to rainbow-tables.

A lot of cold card customers will be waking up confused as to what happened.

Not to mention a lot of people don't have access to the HWW or they are at work or traveling or whatever so they can't just move things. Plus they need a safe seed to move it to. Plus my guess is that anything in the mempool... will only draw attention to vulnerable seeds which will be brute-forced by hungry hackers.

Twitter is saying the bug potentially effects mk3 mk4 and Q devices.

reply

The main line there is that this may not be contained to just mk3. The Coinkite advisory says it does not affect mk4, but as the screenshot shows some people are not sure about that.

The vulnerability is that if you used a mk3 to generate your seed, it is likely not using very good entropy. And so someone else can deduce your private key.

reply

good summary. this should be higher

reply

mk4, mk5, and Q only use 32 bits of cryptographic entropy (when they should use 256) due to the same bug. they are crackable. not trivially crackable like the mk3, but relative to nonbugged entropy, very very very crackable.

reply

my big question is how did no one notice the weakness earlier?

one of my biggest security assumptions, that flaws will be exploited quickly ( so widely adopted and seasoned systems are safe) is being thrown into question

reply

very hard to spot bug: #1536646. also fewer people read the code than you'd think.

reply

i dunno man, if I'm a HW wallet maker.... this is like literally my #1 priority in terms of testing... the true entropy of the wallet

and because of a wrongly specified if then traversal?? this just looks bad

reply

wha whaaaa??

reply
105 sats \ 0 replies \ @so7ow 30 Jul
what's the point of posting an unreadable screenshot and saying "confirmed vuln"? what's the vuln?

Blog post in OP

reply
reply

I wonder if this will cause NVK to be more humble.

All the HWWs he shit on only to have his wallet be compromised is wild

reply

It will be interesting to see where coinkite is as a company in a few years. Have there been any HWW exploits at this scale before?

reply

they are done for, non-recoverable for the business imo

reply

Yeah hard to trust them after this huge gaff.

reply

I think they are still trying to figure out what’s going on. Coinkite is saying it’s wallet agnostic

reply

Are they? I haven't seen anything related to other companies.

reply
reply
205 sats \ 1 reply \ @k00b OP 31 Jul

He deleted this tweet on twitter because he was wrong. TFTC has been a bot account for months.

reply

Ahh can’t delete on nostr! Plus they are an investor in Coinkite. I just hope it’s not a bad as it seems right now.

reply

Thats an old tweet that nvk has since admitted to being wrong. Also, that's not specifying different HWW manufacturers, there's nothing about the other wallets on those transactions that identifies them afaik.

reply
53 sats \ 1 reply \ @siggy47 31 Jul

First thing I wondered too😀

reply

seems unlikely

reply

It's going to cause massive lawsuits. What a great day

reply

Any recommendations on which hww is best to migrate to?
Or would it be best to wait bit and the the dust settle?
I was listening to btc sessions in bitcast and they gave a recommendations and said even the exchanges are safer right now.

reply

FWIW, I moved to a brand new wallet generated on sparrow, just to get it off the CC-seeded wallet. can move to another HWW in time, but for immediate action, this felt appropriate

reply

thanks I moved funds to sparrow but I’m got to wait a bit before buying a new hww

reply
Or would it be best to wait bit and the the dust settle?

No. Even if you have to move it to an exchange or a hot wallet, best to do it now. Do it safely, but do it before it's too late. You can move it back into cold storage after the dust settles.

If you only have the coldcard and don't want to move it to an exchange or hot wallet temporarily, generate a new wallet/seed with 100 or so dice rolls and move all of your old seed's funds to the new one.

reply

thanks I moved to sparrow for the meantime before buying a new hww but is my hww useless now or can generating a seed using dice save the hww?

reply

Using dice rolls will allow you to generate a secure seed on that device and you can still use the hww.

reply

umm I might sound ignorant asking but can I just factory reset it, like a computer and use it as new? I have the Q.
another dumb question 🙋‍♂️
I have a lottery miner mining to that Q wallet, do I reset it as well?
sorry bout the elementary questions.

reply

I don’t have a Q. Use ~AskSN?

reply
93 sats \ 2 replies \ @sime 31 Jul

Im assuming this, but wouldn't multiple entropy inputs mitigate this ?

The non airgapped hardware wallet starting with T get local and remote entropy to protect against a lousy RNG.

reply
13 sats \ 1 reply \ @k00b OP 31 Jul

I recommend reading block's report: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware

The problem wasn't that they lacked a good entropy source. It's that they had a bug that made them choose a bad entropy source.

reply
114 sats \ 0 replies \ @sime 31 Jul

Yes, but entropy mixing allows you to choose the better entropy.

Assuming the mixing itself doesn't have a bug.

reply
83 sats \ 1 reply \ @lrm_btc 31 Jul

I'm way out of my league here, but I thought good rng was something well understood and easily implementable? I figured it was one of the more trivial parts of making a wallet. Definitely strange to me that bad rng could be hidden that long.

reply

It was a tiny bug that caused it to not use the hardware's rng. Even though the good rng was available, the a bug in the software caused it to use a bad rng.

reply

Any word on whether or not multisig is vulnerable?

I have some friends who have multisig setups with Unchained using ColdCards.

reply

If it were me and I created a multisig using only coldcards I would move funds

reply

Yeah. That’s what I am thinking.

reply

wow!!! Man I feel terrible for those who got rugged

reply

I think mempool's next block thingie is gonna turn red pretty quickly...

reply

I've been watching the RBFs.

reply

See any battles?

reply

Some of it was runes lol

reply
3 sats \ 0 replies \ @justin_shocknet 30 Jul -100 sats

Is this the fee-pocalypse we've been scaling for?

https://m.stacker.news/150255

I'm amazed with all the LLM access out there... That this exploit/bug wasn't caught earlier.

The weak entropy of RNG generated seeds in all the devices... Including the mk4 and Q is hard to believe honestly.

The logical conclusion is there will be a lot of sweeping by morning, if I were a hacker (I'm not) I'd be renting GPUs and looking for private keys for each address type or even multisigs being spent. Incredible stuff.

How did noone catch this earlier? Mk3s have been around forever

reply
141 sats \ 1 reply \ @Kruw 31 Jul

Open source code is only useful when you actually read it. Don't take that gift for granted.

reply

I'm amazed nobody put the code in a frontier LLM. Now all the other HWWs will get the same treatment. Will be interesting for sure facepalm

reply

The unthinkable.

reply
73 sats \ 0 replies \ @so7ow 30 Jul

Holy shit.

reply
reply
102 sats \ 0 replies \ @marcocjmr 31 Jul freebie -712 sats

The advisory is thin on the actual defect — "early analysis", formal technical review still to come — so the useful thing right now is triage order, not speculation about the RNG.

First filter I haven't seen raised: was the seed generated on the Mk3, or imported into it? If you imported a seed produced by dice or by another device, the Mk3's random number generator never touched it and you're outside the blast radius. That one question decides whether any of the rest applies to you.

If it was device-generated on 4.0.1 (March 2021) through 5.0.3, treat every address ever derived from that seed as permanently burned — not just the ones currently holding funds. That includes addresses you handed to third parties and anything sitting in a watch-only wallet. Moving the balance fixes the funds; it doesn't fix the exposure.

On the passphrase stopgap Coinkite suggests: it's genuine defense-in-depth, but it sits on the same foundation. An attacker who can enumerate weak seeds still has to brute force the passphrase, so it buys time rather than undoing a bad seed. Coinkite frames it as "interim" and that's exactly right — it's a bridge to a real rotation, not a substitute for one.

Multisig changes the math and nobody's mentioned it: an Mk3 key inside a 2-of-3 doesn't hand anyone your funds on its own. It quietly downgrades you to 1-of-2 effective security. Not an emergency, but don't file it under "unaffected" either.

And following on from the mempool point above — everyone affected is about to bid for the same block space. If you're rotating, move the high-value UTXOs first and at a fee that actually confirms. Cheap-and-patient is the wrong strategy when the entire affected cohort is racing you for the same blocks.

Order that works: new seed on an unaffected device (Mk4, Q or Mk5) → verify offline → small test transaction → then move, largest first.