Just saw this and I thought it was such a shame that he either got ignored or that he didn't dig a little deeper at the time.
He said NVK had blocked him on Twitter.
pull down to refresh
pull down to refresh
Just saw this and I thought it was such a shame that he either got ignored or that he didn't dig a little deeper at the time.
He said NVK had blocked him on Twitter.
Going throughh @nvk 's profile right now.
Most interesting is this thread: #197556 were a Stacker is struggeling to build the firmware in a docker container and nvk does not seem to bother trying to help or try to explain why hashes - and not even filesize - seem to match.
Isn't it sad that all that scrutiny didn't catch the bug either?
sounds like they were all smoke and mirrors
according to the podcast from 2020, @petertodd does not use a hardware wallet
That is correct; I still don't.
I do however use qubes, including on dedicated hardware that I only use for Bitcoin.
https://twiiit.com/peterktodd/status/2083687308193153500
That is what I was thinking. For all the people who are saying the error was novice, the commit notes were shit, and the warning signs were being waved, I sure didn't hear anything too bad about coldcard until a few days ago (except the open source shit).
I don't often make github commits, so I'm not sure what is acceptable there, but things like dusty's article make me feel like apparently absolutely no one looked at their repo before now. But I see that Sjors was a contributor as well as Portland Hodl and Xavier Fiechter, Na Ava Chow and Pythcoiner. These are all serious people who are listed as contributors on Coldcard's github. Am I to believe that they all somehow missed these now glaring process errors and amateur code?
A "Contributor" to a project does not incur any obligation to review existing code. It is the maintainer's responsibility to assure nothing bad gets merged and deployed.
Sure, but presumably, in the process of making their contribution they might have peeked at the existing CC code...
No. That is not a reasonable assumption.
I didn't realize this. Thanks for the clarification.
Just think of it this way: we're both contributors to SN code. Did you review the code I wrote for opentimestamps and see any strange things there?
Think of the Contributors section as an exhaustive list made automatically by GitHub, not those behind the repo. Example: once I did one minor commit for work, did not do anything else, never really took a look at the entire repo and yet was added.
Same for Ledger, I saw someone blaming them but they are not paid to review the code of Coinkite, probably they looked for a vulnerability on the hardware only.
It's easy to in hindsight label something amateur code. If you didn't say it before the breach, your words do not have meaning. There is learning to be done. For all of us.
OP linked a video where it was caught years ago!
If it was caught, why didn't the information spread? That's an even more baffling question imo.
The minimum entropy from dice rolls issue was fixed tho?
So the fucking coldcard had MULTIPLE issues with its key generation at once???
Yes? The issue reported in the video - as I was able to digest by speedplaying and skipping here and there when it got boring, plz do let me know if I missed a point - was a UX problem in the form of a lack of protecting the user from generating a key with 2.585 bits of entropy. NOT the miswiring of the TNRG - especially not because in the last part of the video he speaks about how it is misleading to use the word
mixon a dice-only generation flow, because that would assume the TRNG was called, which it is not. So this guy made the same mistake I and everyone else made: we all failed to test if the TRNG was actually called.Why does that surprise you? There is so much complexity in that flow that ultimately makes discoverability hard. If today I'd have to make a product design pick on such a device for sourcing entropy, it'd be TRNG+mandatory dice, min 50, and that's it. No dice-only, no TRNG only. That's 100% a hindsight thing. But it does take into account that all the masking through added complexity (see also the copy of nullc's HN comment from @Scoresby, it's a good analysis) made this hard to see.
why no dice only with a minimum? @optimism
Because seeding a hash function with randomness instead of an empty buffer (100% determinism) is imho better for a generated secret. It takes the single point of failure out of your dice and (perhaps) the hash function, depending on the error.
Reproducibility of your entropy is cool and I can see that being a thing for some among us, but that is technically
import()for a signer, not secure generation. So while there is arguably also a case for deterministic seed generation alone, I'd scope that out. Deterministic generators do not need random data - it just confuses the issue.wouldnt a trng + 50 dice have led to people not rolling dice and just “randomly” entering numbers? defeating the purpose?
plus doing it that way makes it so the user cant verify the outcome
~lol
👏
🔗 Privacy-friendly: https://yt.chocolatemoo53.com/watch?v=oj_W3xOlt6U
@Darthcoin recommends COLDCARD.