An investigative history into the ColdCard entropy bug
In comment #1539121, I remarked that the more I looked into the ColdCard situation, the worse it seemed. @optimism asked me what I was referring to, but I didn't want to divulge at the time, because I wasn't entirely sure if what I was thinking was accurate. I wanted to get my facts and timelines straight. But I investigated, and now I am ready to discuss what I found.
Background
The core question is when, how, and why the entropy bug entered into ColdCard's firmware. In CoinKite's own post-mortem, they confirmed that the bug was introduced when they migrated away from Trezor-based libraries to libNgU for their cryptographic operations.[1]
This happened on March 1st, 2021, with commit b18723d in ColdCard's firmware repo.
The bigger question is, why did they migrate to libNgU?
Personality conflicts and accusations of copying
Due to all the posts that were surfacing on Stacker News about NVK and ColdCard's past, I came across #172265, where I learned that NVK had gotten into multiple online scraps about proper attribution in FOSS.
In July 2018, NVK got into a bit of a scrape with Pavol Rusnak (cofounder of Trezor) about how ColdCard copied Trezor code but renamed it something else. Rusnak thought they weren't giving proper attribution:[2]
This by itself isn't really that big of a deal. CoinKite was within its rights to copy Trezor's code, because it was distributed under the GNU GPLv3 license, meaning you can copy the code as long you also distribute your code under the same license. Rusnak was simply upset about the naming conventions they chose, which removed the word "trezor" from filenames. But as we'll see, the requirement to distribute under GNU GPLv3 will later play a central role in CoinKite's decision to move away from Trezor-based code.
Moving off GNU GPLv3
Fast forward two years to July 2020. Foundation Devices forks ColdCard's firmware to make its own Passport hardware wallet. This upsets NVK, who accuses them of affinity scamming:
Unhappy that other companies are forking ColdCard's code, he starts thinking about moving to a new license:
The fateful day
On March 1st, 2021, commit b18723d was pushed to ColdCard's firmware library.
The commit message reads "First pass w/ libNgU", and the change log is as follows:
## 4.0.0 - , 2021
- Major internal changes! Minimal external change...
- now using Bitcoin Core's "libsecp256k1" for EC crypto operations
- super fast pure-assembly AES256-CTR code makes USB communications faster
- new optimized SHA256 and SHA256(SHA256()) code in use
- HSM/CKBunker mode:
- users with passwords will have to be recreated as hash used has changed
- Bugfix: CSV of addresses explorer export via Address Explorere, when account number
was used, did not reflect the (non-zero) account number.
- Enhancement: Show a progress bar during slow parts of the login process.
- Enhancement: Paper wallet features restored as they were previously. Same cautions apply.
- Last remaining GPL code removed, so licence is now MIT+CC on everything.So this commit, which wired up the entropy bug, was done (at least in part), so they could move off the GNU GPLv3 license, and move instead to MIT+Commons Clause (which prohibits downstream users from selling the software).
CoinKite's defense
In CoinKite's defense, they argue that the primary reason for migrating to libNgU was to use its libsecp256k1 implementation.
Whether you find this a plausible explanation or not is up to you. None of us can read the minds and intentions of another. However, I was wondering how defensible the claim was that the move to libNgU was motivated primarily by libsecp256k1, so I asked Claude. I won't spoil the response, but if you want you can use the same prompt that I did:
Consider this commit in ColdCard's firmware repo: https://github.com/Coldcard/firmware/commit/b18723dddb6d751c39978e4364b56b2414f68b47
The commit message says "First pass w/ libNgU".
The patch notes say both:
- "now using Bitcoin Core's "libsecp256k1" for EC crypto operations"
- "Last remaining GPL code removed, so licence is now MIT+CC on everything"
I know moving to libNgU was partly due to them no longer wanting to use the Trezor libraries so they can move off GPL. They claim the move was to use libsecp256k1.
To what extent was moving to libNgU necessary for libsecp256k1?Conclusion
The reason I said that "the more I look into this, the worse it seems" is because I started to get the feeling that this whole chain of events was set off by NVK wanting to move off of GPLv3, because he felt that someone had unfairly cloned his code, something that he himself had been accused of just 2 years earlier.
Whether or not you think that was the primary trigger is up to you. I present it only as a possibility. But by CoinKite's own admission, it was the migration to libNgU that wired up the bug on that fateful day of March 1st, 2021.
If anything, it's a good reminder that if you're going to rewire your entire codebase to a new library, you had better do a lot of extra testing before pushing it into production. And you can't just assume that just because it compiles and runs, that all the same assumptions you made with your previous library would hold.
It should be noted that the failure wasn't with
libNgUitself, but rather with how certain preprocessor directives ColdCard already had in place interacted badly withlibNgU. You can read more about it all here: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware ↩Most of the referenced images in this post come from: https://www.zherbert.com/an-open-letter-to-nvk-and-coldcard/. Note that this article was posted in 2023, long before anyone knew about the entropy bug. ↩
He has a weird obsession with "doing the hard stuff". He mentioned the words over and over again over the years.
It's very weird tbh. Linkedin startup bros are weirdos, they're so full of themselves.
ironic because they weren't able to do the hard stuff after all
Was it the hard stuff though? Or did they fail at the easy part?
Good writeup. Thanks.
So... using Trezor software good, rolling your own, not good? Rolling your own is always risky.
I'm still not sure why this context makes it looks bad or could have made it look better in the end. The thing that was deemed needed was to get off GPLv3, for commercial reasons. This caused the change in libs which caused the bug.
What it does do is highlight that a lot of people make money off of open source software. It always sucks when you see someone pull in a couple million in VC rounds by using your effort - though I think that it hurts more when you were not selling anything to anyone. Also happens in other parts of FOSS, think... wordpress.
Regardless, can you explain "how bad it is"?
How bad it is is up to you.
For me I think it seems a bit hypocritical, since he was accused of the same thing earlier, and in a much tamer fashion, and didn't see that he was doing anything wrong (which, I don't think he was). But then he turns around and gets mad when others do same thing.
Also ironic because he accused his "cloners" of having gaping security holes
Lastly, it seems a massive rework of dependencies was done, seemingly in a fit about "clones", without proper testing.
That's why it looks bad to me.
Ok. Yeah the arrogance doesn't really work, but it never does if you have a hidden defect, especially not the one you were being nasty to others about.
I was more thinking that it is bad regardless of how it looks because of the hidden defect staying hidden for so long. It's kind of irrelevant what was said, because even if this was all polite and there was a defect, there would still be no way to recover from this barring a miracle. Cryptography is hard, especially when everything depends on it, especially when there's not enough scrutiny.
Right, there's the question of all the circumstances surrounding an incident... and the incident itself.
The incident itself was bad enough, that all these circumstances don't really change any of that. It would still be bad even if NVK was a perfect angel of a person.
So maybe I am just reacting to the human angle of the circumstances. The drama and the irony.
That's why I asked "do you mean the toxicity?" the other day because from an incident perspective I was like: how can this be any worse? lol
"they argue that the primary reason for migrating to
libNgUwas to use itslibsecp256k1implementation."How the why "defends” incompetent migration I'm unsure, it doesn't. What it does do is reinforce the criticality of RNG to hide your key in the universe, not in a large virus:
And they failed, for five years, while every OG, including me, prated on about NVK and his incredible team.
It doesn't defend against the incompetence, but I guess it makes the motivation look slightly cleaner.
Because right now it seems a little like the whole bug was triggered by anger over someone copying their code under the GPL.
Good work here @SimpleStacker. I was not aware of the Trezor copying thing. That really is rich for NVK. Yet another example of his ego canceling out his intelligence.
"The feeling that this whole chain of events was triggered by NVK, who wanted to get out of GPLv3 because he felt someone had unfairly cloned his code, something he himself had been accused of just two years earlier."
I agree with this; pure revenge.