<sgp_> engineering.block.xyz/blog/predicta…-32-bit-reseed-in-coldcard-firmware

<rucknium> Half of wallet critical vulnerabilities have to be entropy flaws at this point.

<syntheticbird> @rucknium: thats good

<syntheticbird> that means the core wallet library and the most popular ones aren't broken

<thomasbuilds:matrix.org> Someone on X made a valid point that open source is useless unless people look at it.

<thomasbuilds:matrix.org> Pretty sure this vuln was found with AI - it's good at spotting details that humans often miss.

<ofrnxmr:xmr.mx> coldcard isnt open source

<ofrnxmr:xmr.mx> so fuck em

<thomasbuilds:matrix.org> @ofrnxmr:xmr.mx: it is?

<ofrnxmr:xmr.mx> its research-only or some shit

<jpk68:matrix.org> Yeah, I thought it was too

<thomasbuilds:matrix.org> github.com/Coldcard/firmware

<jpk68:matrix.org> You can read the source, it just has some weird IP bullshit attached to it

tl;dr can't sell it, so can't make competitors for it (MIT with Commons Clause attachment)

the point is still similar, source-available, coinkite says they launched AI on it recently and found not that

along sgp_ link there is blog.coinkite.com/entropy-technical-backgrounder as well

<thomasbuilds:matrix.org> DataHoarder: thing is knowing how to use AI and knowing how to code are 2 different skills entirely.

<thomasbuilds:matrix.org> Probably they didn't insist enough in the audit just asked audit the codebase - 1 prompt that's it

<syntheticbird> Just like privacyguides used to say, being open source doesn't mean its secure (because people needs to look at it), but it definitely has more potential to be secure (because people can look at it). > <@thomasbuilds:matrix.org> Someone on X made a valid point that open source is useless unless people look at it.

<ofrnxmr:xmr.mx> brings back memories of mysu (predecessor to monfluo). nobody had the source code after the repo went offline except for r4v3r23

<ofrnxmr:xmr.mx> meaning, sure, it was open source, but also that nobody had ever even cloned it

<sgp_> Schrödinger’s source code

<ofrnxmr:xmr.mx> it doesnt exist until you open the box

<ofrnxmr:xmr.mx> and even then, it may or may not be dead / match the product being shipped

<rucknium> Any opinions on whether diehard tests would have caught this?

Randomness tests typically test the generator, not the seeding entropy.

that reminds me, years ago there was a push to switch to libsodium or Bitcoin's implementation for CSPRNG in monero, but this never went anywhere

<torir:unredacted.org> @rucknium: Seeing as it hashes the result of the bad RNG with SHA256, I don't think any statistical test could have caught it.

<torir:unredacted.org> Unless testing was done before the SHA256 hash, I suppose.

<rucknium> Anyways, I'm going back to dice :D

<rucknium> I couldn't find anything about Coldcard having an audit done.

<jbabb:cypherstack.com> mrelay.p2pool.observer/m/cypherstac…k.com/ErzAMayiLdRCchVBUGxhGPXR.jpeg (ima_a78cbcc.jpeg)

<jbabb:cypherstack.com> reposting an image shared by a coworker--source isn't me, credit isn't mine

<syntheticbird> @jbabb:cypherstack.com: mrelay.p2pool.observer/m/monero.social/dHzhGfxVRlSdZpxxKByHVBLM.png (image.png)

<jpk68:matrix.org> How stupid do you have to be to thing a PRNG is good enough for seed generation

<jpk68:matrix.org> s/thing/think/

<rucknium> I didn't find that code block in the firmware repo. Maybe it's been changed already. But "ideal" turns up some "interesting" comments nonetheless github.com/search?q=repo%3AColdcard%2Ffirmware+ideal&type=code

It was a bug in the code, the PRNG was not being used on purpose. They had an incorrect preprocessor condition.

They used #ifndef MICROPY_HW_ENABLE_RNG instead of #if !MICROPY_HW_ENABLE_RNG

<rucknium> I've seen similar comments in the Monero codebase, but not in the cryptography parts. Some of them are holdovers from the original cryptonote genesis.

<jpk68:matrix.org> monero-project/monero #1271

<jpk68:matrix.org> I could be wrong, but last I checked, this had not been fixed yet

jpk68:matrix.org: the entropy generator changed from intended one to this on one refactor, and even worse, the hw entropy kept being used on other stuff

what hasn't been fixed? That PRNG is secure and uses the same generation scheme as kernel RNG. It doesn't expose the full keccak state to the callers, so it is cryptographically secure

<jpk68:matrix.org> I didn't mean it was a problem, I hadn't really looked into it. It just seems that nothing much has been changed there since the issue was opened

tldr of that report - "it's bad because I don't like it"

no concrete issues reported

<syntheticbird> sech1 can you stop being reasonable ?

<syntheticbird> fearmongering and sensationalism is very important for the health of twitter