Large-scale Coldcard compromise (1596 BTC stolen so far)

[avp2306]

I have seen a lot of folks jumping into the promotion of multi-signature, multi-vendor and/or various forms of collaborative custody, which I find to be potentially overly complicated.

And, yeah, perhaps many of us have lost a decent amount of confidence regarding the ways that seeds have been generated, so then there are some kinds of hardware wallets that allow us to add our own entropy.  I also have gained confidence in the use of passphrases, so I think that a passphrase that is at least 12 characters of numbers, letters, capital and symbols would likely provide enough difficulty to make it quite secure, and sure you could add several more characters if you want a bit more difficulty in your passphrase.

In the end, a passphrase must be stored as part of the seed, adding some complexity.
For sure, it is way simpler than a multisig, with all the required seed conservation isssues.
I am not sure the larger self-custody community is ready for that. I have doubts about myself, too.

Yeah passphrase might really add some complexity. but this is more far easier than managing a multisig wallet.

Maybe best for people to add a passphrase once they already confident by doing verification of their wallet, run a verification test and do seed back ups.

Actually usual problem not comes from passphrase itself. But rather for rushing to add this without knowing how this feature works. But once they already understand those basic things, those added passphrase will became additional useful lock rather than became a burden to those people using it.

[Cricktor]

...

...

Please, learn to quote properly, it's not that hard, unless you fiddle with fat fingers on a mobile phone posting in the forum.


I'm pretty sure you likely have a misconception how weak entropy of approx. 40 bits might actually look like. It's not as simple as you outlined in first quoted part of yours.

What I mean: you could have weak entropy of 40bits or so, however that looks like isn't important. The firmware code then could simply also SHA256 this weak entropy. The result would look totally random with very likely no word repetition when converted to recovery words. It's still only weak entropy of 40bits.

When you know how the flawed PRNG produced weak entropy and you deduced from the firmware code how it was all processed, you still have a fairly limited search space on which you apply exactly what the firmware code did. No rocket science...

[safar1980]

Yeah passphrase might really add some complexity. but this is more far easier than managing a multisig wallet.

Maybe best for people to add a passphrase once they already confident by doing verification of their wallet, run a verification test and do seed back ups.

Actually usual problem not comes from passphrase itself. But rather for rushing to add this without knowing how this feature works. But once they already understand those basic things, those added passphrase will became additional useful lock rather than became a burden to those people using it.

I prefer to use a passphrase. It can be used with many different cryptocurrencies supported by the wallet, and there’s no way to tell if you’re using one. Even if you have to show your wallet to strangers, they won’t be able to tell whether you have the additional 25-word or 13-word protection.

[TheDigitalMan]

...

...

Please, learn to quote properly, it's not that hard, unless you fiddle with fat fingers on a mobile phone posting in the forum.


I'm pretty sure you likely have a misconception how weak entropy of approx. 40 bits might actually look like. It's not as simple as you outlined in first quoted part of yours.

What I mean: you could have weak entropy of 40bits or so, however that looks like isn't important. The firmware code then could simply also SHA256 this weak entropy. The result would look totally random with very likely no word repetition when converted to recovery words. It's still only weak entropy of 40bits.

When you know how the flawed PRNG produced weak entropy and you deduced from the firmware code how it was all processed, you still have a fairly limited search space on which you apply exactly what the firmware code did. No rocket science...

O.K. I hear you. And hashing the entropy with SHA256 does make sense as far as the outcome looking normal.  I also hear you regarding, "With the knowledge of how the firmware was producing entropy and creating the seed phrases" you could search the relatively small amount of space and find them all.  I get that. So what I am hearing is that any one of those seed phrases on their own were probably O.K. was it not for the fact that the wallet software was generating a whole slew of them in the same bracket of numbers. And the fact that it was using only a narrow band of numbers was discovered by the attacker which allowed the jig to be up.

So this is my question. If I through a completely different means of derivation (Let's say I flipped a coin) came up with a seed phrase that fell within the band of numbers the Coldcard wallet was generating its seed phrases within. Then my crypto would have also been at risk.  But not because I generated a seed phrase with weak entropy. No! Only because the Coldcard wallet was creating a honeypot for anyone that disocovered what it was doing. And once that discovery was made and the attacker struck then my wallet would have been swept with all the rest of them. But to be clear, my wallet could have been considered a secure wallet had it not been for the Coldcard incident.  This of course is a completely hypothetical question. I'm just trying to establish that it wasn't the seed phrase itself that was flawed but rather the fact that the wallet was generating all of its seed phrases within a very small subset of the ECDSA number set.  Prior to the Coldwallet incident. If any hardware wallet had created a number inside that subset or if I had created a number by flipping a coin within that subset, everyone would have agreed that it was a perfectly satisfactory seed phrase and that it was secure.  Am I not right in this assertion?  Or is there something else that I am completely missing?

Thanks for reading.  Kresp Rowland.

[decodx]

O.K. I hear you. And hashing the entropy with SHA256 does make sense as far as the outcome looking normal.  I also hear you regarding, "With the knowledge of how the firmware was producing entropy and creating the seed phrases" you could search the relatively small amount of space and find them all.  I get that. So what I am hearing is that any one of those seed phrases on their own were probably O.K. was it not for the fact that the wallet software was generating a whole slew of them in the same bracket of numbers. And the fact that it was using only a narrow band of numbers was discovered by the attacker which allowed the jig to be up.

No. You still don't understand.

Even a single seed phrase was not O.K. It was broken from the start.

The attacker did not just find a pattern in a group of wallets. They figured out how the firmware generated the random numbers. Because the number generator was weak, it only had a tiny pool of possible seeds to pick from. It does not matter if the software makes one wallet or a million wallets. Think of a combination lock. A normal lock has billions of settings. Guessing one takes forever. But this bad code built a lock with only 1,000 settings. The attacker just runs through all 1,000 possibilities (not the exact number; I'm exaggerating here) on a computer in a few seconds. They check every single seed in that small pool. If they find wallet with funds in that pool, they take the funds.

So this is my question. If I through a completely different means of derivation (Let's say I flipped a coin) came up with a seed phrase that fell within the band of numbers the Coldcard wallet was generating its seed phrases within. Then my crypto would have also been at risk. 
<...>

Technically, it is possible. But highly unlikely.

If you're flipping a coin 256 times to generate your seed, that means you're using true randomness and good entropy. Your seed will be picked from trillions of possible combinations. Your odds of hitting one of those specific weak numbers are practically zero.

[LoyceV]

So this is my question. If I through a completely different means of derivation (Let's say I flipped a coin) came up with a seed phrase that fell within the band of numbers the Coldcard wallet was generating its seed phrases within. Then my crypto would have also been at risk.

If the last 75% of your coin flips are all the same ("0"), then indeed, this is a risk. But that's not going to happen.

[TheDigitalMan]

Thank you, decondx, for responding. I actually read your response with interest and everything you said I actually agreed with. So at the very least I do understand what you are saying.

I want to continue the conversation using your exaggerated small numbers to re-phrase my question in a way that maybe everyone will understand what I am trying to get at. So the attacker figured out how the firmware generated the random numbers and basically re-generated the list of them, let's use the 1,000 figure that you used. He checks those 1,000 seeds and takes any bitcoin he finds. Now in this same non-existent universe I, Kresp Rowland, am getting ready to launch a Hardware Wallet company.  I'm about to go live with my marketing campaign and the Coldcard wallet exploit takes place. I decide even though you did say it was "Technically, possible. But highly unlikely." that my Hardware Wallet should "CHECK for those numbers" when generating the random seed number and if one is accidentally picked I would have my Hardware Wallet re-pick another number. I have a confab with my engineers and they write a whole additional subroutine in my Hardware Wallet code to specifically skip around the 1,000 numbers that the Coldcard wallet was using. Would that not be a prudent thing for a Wallet Hardware manufacturer to do?

Sticking with the 1,000 number (To keep the conversation sane even though we both know the numbers we're working with are larger in our actual universe) let's say my engineers find that the Coldcard was generating all of its seeds between 67,500 and 68,500.  Let's say for the sake of conversation that the entire ECDSA space that all bitcoin seeds are being generated from is 100,000. (I know in our universe it's 1.15^77). So the chances of randomly picking a number that falls within the 67,500 thru 68,500 space is unlikely as you stated earlier.  But technically possible. It seems like it would be a trivial thing to exclude these 1,000 numbers from a seed picking subroutine.  Unless the numbers are not neatly grouped together like I have described.  Perhaps their are 10 of them in 100 groups.  For example maybe 935 - 944 represent the first 10 of the 1,000 numbers.  Then 1,935 - 1,944 represent the 2nd 10, 2,935 - 2,944 represent the 3rd 10, all the way to 99,935 - 99,944 representing the last 10. Ten numbers occurring in each of the 100 sets of a thousand throughout the ECDSA space.  If this is how the Coldcard distributed its weak entropy then writing a subroutine to exclude those numbers would be more difficult. And posting a list of them on your office wall so that you could make sure that any of your coin flips did not pick one would be difficult since the list would be over a trillion numbers in size. With 40 binary bits set to 1 you get 1 trillion 99 billion etc.  It was also my understanding that one of the other models generated closer to 72 bits of entropy. So that would be an even larger pool of numbers.  But if the numbers were grouped into a tight subset as in the first half of my example. i.e. 67,500 thru 68,500.  If this is the case then I would like to know what that range is?

I am not getting ready to launch a Hardware Wallet company.  I simply used that as an example.  But I have been working on a security project relating to the Seed Phrase and the Private Key.  I would love to have some of this information regarding the actual seed numbers the Coldcard wallet was picking to include in my project. So besides the attacker, has no one bothered to re-create the attack? Has no one bothered to create the set of seed numbers that the attacker created?  This is what I am interested in doing.  But I am a bit unsure on how to get started. This is where I have been running into a bit of a wall.  But perhaps it's not as simple as I'm trying to make it out to be?  I assume the firmware code is complicated? If anyone can help me in this endeavor I would definately be interested.  If anyone can offer to sell me a Coldcard wallet with the flawed firmware still installed on it I would definately be interested.

RE: LoyceV's response.  So after getting my 128 bits or 256 bits of entropy, what I'm hearing you say is that as long as it looks random it's probably O.K.?  As long as I don't have long runs of 1's or 0's over 20 or 30 in a row then the number is most likely acceptable?  I agree it is highly unlikely that a coin would land on heads or tails over 100 times in a row. Or that you would roll boxcars or snake eyes on a pair of dice over 50 times in a row.

The frustrating part for me is that you can't look at the entropy and determine if it's secure or not just by looking? But I guess at the end of the day you're really just picking a number between 1 and 1.15^77.  As long as you don't select a small number under a few quadrillion and as long as you don't pick one of the Coldcard's numbers you should be good?

Thank you for your time.

Kresp

[Cricktor]

Could you please break down your walls of text a bit, it's realy somewhat a pain to read.

I'm not going to play with your numbers. AFAIR from a breakdown of flaws of defective Coldcard firmware, when the TRNG was skipped and not used for wallet entropy generation and a weak PRNG that basically produced only 32bits of entropy was used in the remaining code path, this is a severe issue. Defective Coldcard firmware code also mangled chip-wafer-location and (only vaguely remembered by me) some device serial no. In the case of the Coldcard MK4, if I don't mix it up (I don't care about Coldcard much), all those bits with the weak PRNG added up to roughly 40bits of variable entropy, where it should've been at least 128bits for 12 recovery words or 256bit for 24 of them.

Now if you know from reading the ("source verifiable", aka readable) source code how the firmware processed all of it, you know what to precalculate with a search or generation space of approx. 40bits. That is manageable for a dedicated attacker to precompute and check for derived addresses and where there are funds that could be stolen, because the attacker can generate all seeds the defective Coldcard firmware would've ever generated.

That's the gist of the Coldcard debacle, so to say with few words.


If you throw a mostly fair coin, it's highly unlikely to get a streak of 20, 30, 40 or more consecutive heads or tails. By probability not impossible but the likelyhood is extremely low. The probability to throw 20 consecutive heads OR tails for a fair coin is 0.5²⁰ and this is only 0.000000953674 and for sure it doesn't get better for 30 or 40 consecutive ones, on the very contrary!

The frustrating part for me is that you can't look at the entropy and determine if it's secure or not just by looking?

Humans are not made to be able to judge if something is truely random or not. And humans are also commonly pretty bad at generating "good" entropy. You can't realy point a finger at something and say: "This is random!"

At least, I wouldn't want to rely on something like this.

[PrivacyG]

I have a confab with my engineers and they write a whole additional subroutine in my Hardware Wallet code to specifically skip around the 1,000 numbers that the Coldcard wallet was using. Would that not be a prudent thing for a Wallet Hardware manufacturer to do?

I get your worry and I do not necessarily believe it is a bad idea to skip the Seeds a vulnerable Coldcard firmware generated but I do believe you are overly thinking this to a point where you are worrying too much about some thing that is simply not probable.  Because at this point you can also start worrying about possibly generating a Seed that collides with another previously used one.  It is technically possible but it will probably never happen either.

There must be some body out there in this World insane enough to have a significant collection of unused Seeds with some kind of bot that constantly checks for new Transactions so they could steal from them if any of them ever become active.  What do you do then?  If you think only about how many of us generated at least ten Seeds, you would think the probability must now be very high to find a collision.  I do not know if the effort of skipping these Coldcard Seeds range would be of any help ever at all if a Wallet generation process follows the Bitcoin standards and not a very limited version of it, but I am some how conflicted because at the same time I do not think it would be a BAD idea to do that either, because what if it actually happens.

[philipma1957]

Thank you, decondx, for responding. I actually read your response with interest and everything you said I actually agreed with. So at the very least I do understand what you are saying.

I want to continue the conversation using your exaggerated small numbers to re-phrase my question in a way that maybe everyone will understand what I am trying to get at. So the attacker figured out how the firmware generated the random numbers and basically re-generated the list of them, let's use the 1,000 figure that you used. He checks those 1,000 seeds and takes any bitcoin he finds. Now in this same non-existent universe I, Kresp Rowland, am getting ready to launch a Hardware Wallet company.  I'm about to go live with my marketing campaign and the Coldcard wallet exploit takes place. I decide even though you did say it was "Technically, possible. But highly unlikely." that my Hardware Wallet should "CHECK for those numbers" when generating the random seed number and if one is accidentally picked I would have my Hardware Wallet re-pick another number. I have a confab with my engineers and they write a whole additional subroutine in my Hardware Wallet code to specifically skip around the 1,000 numbers that the Coldcard wallet was using. Would that not be a prudent thing for a Wallet Hardware manufacturer to do?

Sticking with the 1,000 number (To keep the conversation sane even though we both know the numbers we're working with are larger in our actual universe) let's say my engineers find that the Coldcard was generating all of its seeds between 67,500 and 68,500.  Let's say for the sake of conversation that the entire ECDSA space that all bitcoin seeds are being generated from is 100,000. (I know in our universe it's 1.15^77). So the chances of randomly picking a number that falls within the 67,500 thru 68,500 space is unlikely as you stated earlier.  But technically possible. It seems like it would be a trivial thing to exclude these 1,000 numbers from a seed picking subroutine.  Unless the numbers are not neatly grouped together like I have described.  Perhaps their are 10 of them in 100 groups.  For example maybe 935 - 944 represent the first 10 of the 1,000 numbers.  Then 1,935 - 1,944 represent the 2nd 10, 2,935 - 2,944 represent the 3rd 10, all the way to 99,935 - 99,944 representing the last 10. Ten numbers occurring in each of the 100 sets of a thousand throughout the ECDSA space.  If this is how the Coldcard distributed its weak entropy then writing a subroutine to exclude those numbers would be more difficult. And posting a list of them on your office wall so that you could make sure that any of your coin flips did not pick one would be difficult since the list would be over a trillion numbers in size. With 40 binary bits set to 1 you get 1 trillion 99 billion etc.  It was also my understanding that one of the other models generated closer to 72 bits of entropy. So that would be an even larger pool of numbers.  But if the numbers were grouped into a tight subset as in the first half of my example. i.e. 67,500 thru 68,500.  If this is the case then I would like to know what that range is?

I am not getting ready to launch a Hardware Wallet company.  I simply used that as an example.  But I have been working on a security project relating to the Seed Phrase and the Private Key.  I would love to have some of this information regarding the actual seed numbers the Coldcard wallet was picking to include in my project. So besides the attacker, has no one bothered to re-create the attack? Has no one bothered to create the set of seed numbers that the attacker created?  This is what I am interested in doing.  But I am a bit unsure on how to get started. This is where I have been running into a bit of a wall.  But perhaps it's not as simple as I'm trying to make it out to be?  I assume the firmware code is complicated? If anyone can help me in this endeavor I would definately be interested.  If anyone can offer to sell me a Coldcard wallet with the flawed firmware still installed on it I would definately be interested.

RE: LoyceV's response.  So after getting my 128 bits or 256 bits of entropy, what I'm hearing you say is that as long as it looks random it's probably O.K.?  As long as I don't have long runs of 1's or 0's over 20 or 30 in a row then the number is most likely acceptable?  I agree it is highly unlikely that a coin would land on heads or tails over 100 times in a row. Or that you would roll boxcars or snake eyes on a pair of dice over 50 times in a row.

The frustrating part for me is that you can't look at the entropy and determine if it's secure or not just by looking? But I guess at the end of the day you're really just picking a number between 1 and 1.15^77.  As long as you don't select a small number under a few quadrillion and as long as you don't pick one of the Coldcard's numbers you should be good?

Thank you for your time.

Kresp

Your worry is a simple misunderstanding of math.

Let's say the full field is 256 bit

Lets say the short field is 40 bit

The odds of you picking at random from a correctly done 256 bit are about 256-40 = 216 bit

Ie 1 trillion is 40 bits.

So 1 trillion x 1 trillion x 1 trillion x 1 trillion x 1 trillion x 1 trillion is only 240 bits.

1trillion x 1trillion x 1trillion x 1 trillion x 1  trillion x 1 trillion x 1 million is 262 bits

So you are asking if

1 trillion x 1 trillion x 1 trillion x 1 trillion x 1 trillion x 1 million is unsafe.  The answer is no it is perfectly or very close to perfectly safe.


Here's is another way to understand a trillion .

If the entire human race counts to 125 we have 1 trillion it takes a minute which is possible and why the hack happened.

But now have us do it 1 trillion times each and that is 1 trillion minutes. Or about 1,900,000 million years.

You only cover 1 trillion x 1 trillion in the human race example and time gets long. Square 1,900,000 years  and you are at a number longer than the age of the universe..

And you are only at 1 trillion to the fourth.  So in practicality your fear won't happen.

[TheDigitalMan]

Gentlemen,

I appreciate everyone taking the time to reply.  I guess at the end of the day everyone is correct when they point out that the pool of numbers we are picking from is so large that it's basically impossible to pick the same number as someone else in a persons lifetime unless they are not picking randomly.

I do understand that the ECDSA space represents a pool of numbers roughly 1.1579 x 10^77.  Considering that most scientists put the number of atoms in the known observable universe at somewhere between 10^78 and 10^82 it means there are almost as many different possible bitcoin keys as there are atoms in the universe.  And when you consider a medium grain of sand contains roughly 5 quintillion atoms or a drop of water holds around 5 sextillion atoms and you're not even getting close to the number of ECDSA keys even after exhausting every single grain of sand and drop of water on this planet or even in this solar system it kind of puts things into proper perspective. To think there are 5 quintillion different private keys available in one grain of sand and I think of all the sand in the Sahara desert or on the planet Mars. It does boggle my mind.

I have been working on a project that involves the "Seed Phrase" and how to keep it secure since 2018 and I'm going to be presenting it at the Bitcoin Conference in Nashville, TN this next year, July 15-19, 2027.  When the Coldcard incident occurred it just made me re-think everything I thought I knew about the Seed Phrase and the security of it.  I felt it only appropriate to research the Coldcard exploit and to be sure I wasn't missing anything regarding the theories and education that I was putting into my project.

I am satisified that the system of Private Keys for Bitcoin and how they are derived using the secp256k1 eliptic curve is intact and robust as, mabji1, put it.

I appreciate everyone being patient with me. I do think more bitcoin will be lost by people jumping on the multi-sig wallet bandwagon over this event and then losing track of how to retrieve it.  I am satisified that a single sig solution is perfectly secure. I also believe in having more then one seed phrase. I am all in on self custody and I am looking forward to next years bitcoin conference.  The Coldcard incident is just an unfortunate footnote in bitcoin's history.  My heart goes out to those who lost bitcoin to it.

I am closing my investigation into all this and will move forward.

Cheers

Kresp Rowland

[ryzaadit]

This one is quite funny.

We all know that after this incident, no one gonna to believe them anymore, even if they make some firmware updates and other things (the trust is already lost). These stories are from the Reseller who sells the ColdCard Device.

September 5th, 2026

Bitcoin Brabant posted and made a poll about their stash of ColdCard devices to the community. The polls ended with 53,5% for "Don’t list the coldcards", these leave the reseller with such a huge stash device can't be sold. Who on earth is gonna buy their device right now?

However, ColdCard seems to be forcing the reseller who still has stock of their device to keep selling their faulty devices product even though they can't be sold anymore since no one trusts their device anymore. But the response is quite funny; they're claiming they received requests from multiple sellers to request more stock of their device.



~LOL did everyone gonna trust their claim blindly.

Now, today seem they're gonna face legal action from the Reseller Bitcoin Brabant since he said he's speaking with a lawyer right now to get some pile of lawsuits. Since ColdCard is not answering anything about their request.





Potential losses from their faulty device $58,760.22 with total product 265.
This could lead to other resellers doing the same thing by taking legal action since they no longer have the ability to sell their faulty product, even though ColdCard guarantees to replace the product with a newer one. But of course, no one buys it either.

I guess we are gonna see not just a legal action from the victim but also from the reseller. Anyway, he's asking the community:

We are working with lawyers to get on the pile of lawsuits, but what is realistically the chance here?
What do you think we should do?

Source: https://x.com/BitcoinBrabant/status/2100839867018051693

Any chance for him to at least get a refund for the product?

Source:
[1] https://x.com/BitcoinBrabant/status/2095976832411533423
[2] https://x.com/BitcoinBrabant/status/2100839857434099788

[philipma1957]

This one is quite funny.

We all know that after this incident, no one gonna to believe them anymore, even if they make some firmware updates and other things (the trust is already lost). These stories are from the Reseller who sells the ColdCard Device.

September 5th, 2026

Bitcoin Brabant posted and made a poll about their stash of ColdCard devices to the community. The polls ended with 53,5% for "Don’t list the coldcards", these leave the reseller with such a huge stash device can't be sold. Who on earth is gonna buy their device right now?

However, ColdCard seems to be forcing the reseller who still has stock of their device to keep selling their faulty devices product even though they can't be sold anymore since no one trusts their device anymore. But the response is quite funny; they're claiming they received requests from multiple sellers to request more stock of their device.



~LOL did everyone gonna trust their claim blindly.

Now, today seem they're gonna face legal action from the Reseller Bitcoin Brabant since he said he's speaking with a lawyer right now to get some pile of lawsuits. Since ColdCard is not answering anything about their request.





Potential losses from their faulty device $58,760.22 with total product 265.
This could lead to other resellers doing the same thing by taking legal action since they no longer have the ability to sell their faulty product, even though ColdCard guarantees to replace the product with a newer one. But of course, no one buys it either.

I guess we are gonna see not just a legal action from the victim but also from the reseller. Anyway, he's asking the community:

We are working with lawyers to get on the pile of lawsuits, but what is realistically the chance here?
What do you think we should do?

Source: https://x.com/BitcoinBrabant/status/2100839867018051693

Any chance for him to at least get a refund for the product?

Source:
[1] https://x.com/BitcoinBrabant/status/2095976832411533423
[2] https://x.com/BitcoinBrabant/status/2100839857434099788

I do not think he gets a refund.  My guess is he could get a judgment saying he is due the refund. But that there will be no funds for it.

[tvbcof]

...

I do not think he gets a refund.  My guess is he could get a judgment saying he is due the refund. But that there will be no funds for it.

The hardware itself is nothing of particular value due to poor implementation.  Again, 2 out of 3 of my devices had hardware failures within a very short duty time.

Worse than that, the whole idea of ANY air-gapped device holding critical parts of key material is in serious question for high security work.  Knowing how effective hardware attacks can be makes me a big fan of stateless devices.  Even here, it must be certain that no residual data can be, by accident or design, tucked away (in caches and what-not) for potential retrieval.

Hopefully someone goes for compensation in terms IP rights to any claims made by Coinkike, or at least put them under legal question so these creeps cannot so easily benefit from them.  I cannot do it since I've suffered no losses.

[Leon Zimmer]

The hardware itself is nothing of particular value due to poor implementation.  Again, 2 out of 3 of my devices had hardware failures within a very short duty time.

Worse than that, the whole idea of ANY air-gapped device holding critical parts of key material is in serious question for high security work.  Knowing how effective hardware attacks can be makes me a big fan of stateless devices.  Even here, it must be certain that no residual data can be, by accident or design, tucked away (in caches and what-not) for potential retrieval.

Hopefully someone goes for compensation in terms IP rights to any claims made by Coinkike, or at least put them under legal question so these creeps cannot so easily benefit from them.  I cannot do it since I've suffered no losses.

That bug survived for 5 years in open source code that was presumably being "reviewed". For most, "verify the firmware" amounts to glancing for obvious backdoors, not auditing entropy sources, which would be much more useful. Unless some entropy-qualified person specifically audits the entropy source, the vast majority won't dig that deep.

[tvbcof]

...

That bug survived for 5 years in open source code that was presumably being "reviewed". For most, "verify the firmware" amounts to glancing for obvious backdoors, not auditing entropy sources, which would be much more useful. Unless some entropy-qualified person specifically audits the entropy source, the vast majority won't dig that deep.

All true.  This was a place where I made a mis-calculation.  Rightly or wrongly I believed the device to be in use by relatively high value entities who had a desire and an obligation to do somewhat careful analysis of the devices they use.  This elevated my estimate of the eyeballs who were probably evaluating the device for weak points.

I am not terribly surprised that the specific bug when as long as it did without third-party detection.  I would almost expect such a thing for 'ordinary' code with relatively standard costs of failure.  It is true that it was at something of an intersection of systems so the most likely to notice it would be people who were architecting all elements of the device.  That a bogus third party maintained crypto library which was a part of the 'problem' and that it was implemented by a couple of sock puppets operated the the Coinkite CTO is well beyond suspicious to me.  Not buying it.

But anyway, I'm just re-hashing what many others have already said about their feelings on the matter.

I do remember when researching for a hardware device someone who I've respect for saying something like 'A lot of people are going to get burnt one day.'  I don't recall exactly who it was, but I think it was one of the Bitcoin core folks, and they were speaking of hardware wallets more generally and not Coldcard specifically.  I'm pretty sure it was specifically about entropy 'defects' though.  I remember thinking to myself 'I hope I am not one of them', but actually the words haunted me all the way up until 'C-day'.  I guess it's good to listen to one's gut senses.  And also, don't rely on 'hope' to protect things of importance.