Replies (22)

wow. i dont write code that sloppily for my side projects, let alone at work, let alone on software this critical. “runs” unbelievable.
Not to justify things, but this was in front of everyone's eyes for 5 years. Therefore I assume: a) nobody looked at it, b) some looked at it and didn't bother to further investigate, c) some looked at it, investigated, and the findings were quietly buried. I.e., it was known but inconvenient to act on, d) some saw it, investigated, understood the severity, but lacked the authority or leverage to force action.
Solo dev just casually writing the "most secure" hardware wallet on the market. "runs" NVK turns out to be a complete LARP grifting the entire space.
This just goes to show that "it's open source" is never sufficient to make a case that the code is correct, secure, or even works. Only when people build on that code and actively use it in their own projects do these kinds of bugs get found. And NVK spent his every waking hour to ensure that never happened.
Vincent Anton's avatar
Vincent Anton 3 weeks ago
This is troubling: From here, I assume in a bout of frustration, he set `MICROPY_HW_ENABLE_RNG` to 0, which would have resolved the compiler error.
He’s the coinkite CTO. It’s well known in technical circles. NVK has always been the marketing/hype man. Doc hex aka Peter gray is the tech “wizard” at coinkite
We were all trusting that someone had verified. Meanwhile, the whole thing was a clown car built by the intern who knew how to write Python but not C.
He let's the company off the hook here. This was probably some intern or jr engineer under ship pressure. Devs need help understanding their code. As a test engineer this is worse than a mistake, it looks like criminal negligence. When you create a verification matrix the first thing you consult is the things you promised your customers. Marketing points in this case. If you say you have 256b of entropy supplied by a hardware element, your test must verify those things after any significant design change, to as high a level of real world veracity as possible. Anyone who signed off on this code or the (lack of) verification process is potentially criminally liable. You are not reasonably expected to find every bug. You ARE reasonably expected to verify your marketing points. A simple entropy test, or even just polling the hardware element logs to verify they are actually accessed, would be a very basic hardware in the loop test I would expect as a minimum for this kind of product.
I read the entire article. My first pass opinion: Hardware Wallet Co's should not even be using hardware that offers a low / fake entropy option to a C Programmer. Use the correct entropy source or your compile fails. There should be no "fallback" option, e.g. yasmarang or whatever.
ColdCard is not open source which was exactly part of the problem. Open Source and Source Verifiable code are *not* the same and don’t offer similar benefits in terms of community involvement, more eyes reviewing, and more people building on that code.
What I dont understand is, in an industry so focused on security, how did this go unnoticed? I mean, it looks to me like basic software engineering principles were neglected, so why was that not noticed? It might very well be that its a "hindsight is 20/20" kind of thing, but it just doesnt seem like the bug was really all that hard to identify. There has been attempts to make this seem like it was only possible to identify this bug with amazingly intelligent cutting edge AI, but it kind of seems more likely to me that *no one* actually even took the time to review the code at all before this event. Now that all hell broke lose, it seems so trivial to identify the bug. Obviously, also in hindsight, it is so easy to see the red flags of NVKs arrogance, finger-pointing, whining about people building on top of his ideas and especially the "open verifiable" disaster.