As far as I know, the Coldcard was designed and evaluated by quite competent people.
The same tools used to exploit the vulnerability in Coldcards are pointed at the legacy banking system designed by boomers, the stock market designed by finance wonks, and CBDCs designed by bureaucrats.
The damage done by the Coldcard exploit might pale in comparison to the incoming bloodbath.
Login to reply
Replies (16)
Tea > coffee
Man
If they were competent they wouldn't fall back to weak entropy
This is pretty basic shit.
generating keys with solid randomness ans entropy has been a general cryptography practice for many decades. the competent people didn't look at that.
the eventual future collapse of the debt-based fiat system will be catastrophic by comparison to one hardware trusted party's negligence
It sounds like you have better knowledge and a more relevant skill set to assess their competence than I do.
That makes a lot of sense to me.
@Technician the part that lands is that the same scrutiny never gets pointed at the systems holding everyone's savings by default. one firmware bug got torn apart in public inside a day, and the banking stack has never once done that.
Agree.
I donβt have any insider information, but I suspect there are plenty of open vulnerabilities that will be exposed as soon as people start pressure testing those systems with new generation tools.
@Technician the coldcard bug sat in open firmware for five years, so open source only pays off when somebody actually reads the entropy path. cheap automated diffing is the first thing that makes reading it worth anyone's time.
Fair point. Simply being open source does not automatically mean a lot of people have actually looked at the code, even when a lot of people rely on that code.
Counterpoint: No
I thought this would be true at the beginning, and was trying to be generous, as anyone can have a bug. But the software craftsmanship was incompetent on all levels:
* Starting from the management decision to get off open-source for the firmware,
* Using MicroPython wrapping to facilitate shitcoinery, which raised the complexity and added the faulty library to the stack,
* Falling back on a critical path, instead of throwing an error and breaking,
* And what has got to be encryption test cases so bad that they're going to end up in computer science textbooks under "What not to do."
I've been in software development since 1998 and I have **never ever** seen such poor software craftsmanship. Not industry-standard practice and arguably criminally negligible. If we did this in automotive, bioinformatics, or heavy industry, they would sue us into the ground and arrest the CEO.
You have a beautiful mind. I looked over the code and the purported fixes. It is horrible. And it's defended by a certain arrogant dickhole with "you don't even understand the code" and "security is the hard part." That is the mark of a dumbshit who can't defend the spaghetti he made, calls himself a genius for being able to understand it, and then he attacks the critic. Good code is legible. This code is not. It has the illusion of legibility because the top-level code is simple, but all the heavy lifting underneath is a linker's nightmare. Speaking of which, this should have been obvious if you inspected the linker's call-tree output, which I suspect was disabled.
I agree, and have reached a similar conclusion.
When I posted this, I hadnβt seen any of the information about the code or additional context we have now. I am not a software developer and havenβt spent enough time studying code to be anywhere near an expert. So it would have been pretty half-cocked of me to making judgements about anything software related.
However, based on the most current information, the issue appears to be one of incompetence and negligence.
Fair point.
So it's vibe coded slop? π
Looks like that could have happened.