[flagged]
When random.bytes() runs but doesn't work
41–50 of 63 posts
Re: When random.bytes() runs but doesn't work
#42Earlier quoted context omitted.
Also: writing this stuff in C just begs for bugs. LLM agents are cheap and good enough that you can write in eg Lean or whatever. Or at least write it in Rust.
I get the feeling that the bugs found in this instance can be more directly attributed to the author having zero experience operating a microcontroller
Honestly, I'm going to be a bit harsher: I think they're either:
1. A novice who doesn't know how to debug issues.
2. Totally incompetent and copying code from Stack Overflow.
I don't think it's specific to microcontrollers, either, the error from the C compiler is something that a competent programmer would be able to interpret, or at least see it as a signal to get someone more experienced in the domain to learn about.
Re: When random.bytes() runs but doesn't work
#43Earlier quoted context omitted.
No, via direct deposit. I had a co-worker once who miskeyed his routing+account numbers and guess what? He still got his money a few days later and it wasn't lost to the void. There is no blockchain, seed phrases, nor cold wallets required for this amazing feat of money transfer/remediation to take place.
Great! Maybe the government should stop over regulating the banking system so the same protection will also be available to someone who buys drugs.
Wait, is the argument now that cryptocurrency only exists and is useful for buying drugs? It's tough to keep track of what point you're trying to make
Re: When random.bytes() runs but doesn't work
#44From the Twitter advisory on the issue being referenced here [1]: >>> To every other developer: we believe this is a sober reality of the new AI paradigm. AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts. If your firmware is open-source or has ever been public, assume it's already being read by attackers and defenders alike. Kinda turns the “many…
If the industry most seasoned experts are not using LLMs right now to front-run the discovery of vulnerabilities in the code they are responsible for, they are not experts, but clowns.
A lot of the vulnerabilities being discovered are low hanging fruit. An LLM could discover them, but so could a human.
Let me amend your statement:
If the industry most seasoned experts are not engaging in regular security reviews of their firmware, they are not experts, but clowns.
LLMs are useful for this but not absolutely necessary to address the core issue.
Re: When random.bytes() runs but doesn't work
#45> You, as a developer working on Bitcoin, need to take your time to understand your changes, document them clearly, and verify they do what you think. Or, you could realize that using a financial technology which relies on no software bugs ever is probably flawed at its core. "Not your keys, not your coins" was (is?) the zeitgeist but even people who did the "right thing" and used a cold wallet still got screwed. I d…
The "right thing" here is subjective.
If one uses a good source of entropy (e.g. dice rolls) then one will not "get screwed."
> I don't know why anyone would keep their wealth in something that requires so much technical excellence.
It's not for everybody, for sure.
Re: When random.bytes() runs but doesn't work
#46> You, as a developer working on Bitcoin, need to take your time to understand your changes, document them clearly, and verify they do what you think. Or, you could realize that using a financial technology which relies on no software bugs ever is probably flawed at its core. "Not your keys, not your coins" was (is?) the zeitgeist but even people who did the "right thing" and used a cold wallet still got screwed. I d…
The "right thing" here is subjective. If one uses a good source of entropy (e.g. dice rolls) then one will not "get screwed." > I don't know why anyone would keep their wealth in something that requires so much technical excellence. It's not for everybody, for sure.
> If one uses a good source of entropy then one will not "get screwed."
How many users were told to verify the source code to make sure it was using good entropy? How many would actually do that even if told? Obviously not even the most hardline bitcoiners were looking at it.
> dice rolls
Yes, the new cope I've seen is that you should've been using casino-grade dice[1] to make sure your entropy is good LOL. Mass adoption soon, I'm sure.
1: https://old.reddit.com/r/Bitcoin/comments/1vcr4r4/dice_rolls...
Re: When random.bytes() runs but doesn't work
#47Earlier quoted context omitted.
No, via direct deposit. I had a co-worker once who miskeyed his routing+account numbers and guess what? He still got his money a few days later and it wasn't lost to the void. There is no blockchain, seed phrases, nor cold wallets required for this amazing feat of money transfer/remediation to take place.
Great! Maybe the government should stop over regulating the banking system so the same protection will also be available to someone who buys drugs.
If your argument is that Bitcoin is only good for illicit purchases, then I sort of agree with you but there are better alternatives like Monero. Regardless, you would agree that current valuations are insane given that's the only real use-case, right?
Also infrequent purchases != storing wealth in Bitcoin.
Re: When random.bytes() runs but doesn't work
#48Earlier quoted context omitted.
At no point did I ever think that setting "enable HW RNG" to 0 "provided a more aggressive handling of fault/error conditions". I always assumed it disabled the HW RNG.
https://github.com/switck/libngu/blob/537519a829259622ea6b03... vs https://github.com/Coldcard/micropython/blob/4107246f8a08080...
The my_random_bytes implementation doesn't look good at all at first glance. Let's see:
1. I believe it errors out if the HWRNG returns the same value twice. That's actually a thing that can legitimately happen. "0" is also a legitimate output.
2. "here" is a terrible name for a length
3. It does a memcpy of a minimum of 4 bytes to the destination, even if count is lower. It'll also overflow longer buffers with a length not divisible by 4.
Re: When random.bytes() runs but doesn't work
#49This writeup isn't very good and misses/misunderstands the programming error that leads to the flaw. I'm commenting because I think it's important to understand the issue. The article would have you think that the change in question was a tiny change to a flag to make it compile, but in reality the commit in question is a 1533 line addition of the entire RNG infrastructure. The fundamental cause is a mixup between a…
The article clearly indicates the size of the changes: "The commit message is 5 characters and is simply the word “runs.” The commit changes 1534 lines of code making the ratio 5/1534 = ~0.003"
Re: When random.bytes() runs but doesn't work
#50Earlier quoted context omitted.
https://github.com/switck/libngu/blob/537519a829259622ea6b03... vs https://github.com/Coldcard/micropython/blob/4107246f8a08080...
The my_random_bytes implementation doesn't look good at all at first glance. Let's see: 1. I believe it errors out if the HWRNG returns the same value twice. That's actually a thing that can legitimately happen. "0" is also a legitimate output. 2. "here" is a terrible name for a length 3. It does a memcpy of a minimum of 4 bytes to the destination, even if count is lower. It'll also overflow longer buffers with a len…
I have absolutely no interest in defending this code-- and already considered it untrusthworthy before any of this. But in the interest of accuracy:
> It does a memcpy of a minimum of 4 bytes
This is a common misreading of MIN(). MIN(4,x) is a number that is a MAXIMUM of 4, not a minimum.
Count is the number of bytes remaining in the buffer. The input to the copy is a 4-byte word. min(4,count) will produce a number 0-4 which is always equal to or less than count. The copy will not overflow the buffer or overrun the input: If count is 3, for example, then here will be 3 and it will copy 3 bytes.
> believe it errors out if the HWRNG returns the same value twice. That's actually a thing that can legitimately happen. "0" is also a legitimate output.
It's been a while since I looked but I believe the STM32 manual advises you to throw away data when this happens, because the rng is updated async with the processor and reads that are too fast will produce 0s or duplicate values. Entropy loss from doing so is generally negligible. Were it me I'd read enough into a cryptographic hash to render the output cryptographically close to uniform and not have to worry about it further. (particularly since some uses of cryptographic numbers are extremely sensitive to even small biases)
I do wonder how fatal MP_EFAULT actually is...-- on a device like this being jumpy at failing the RNG is reasonable, but if it bricks the device (for example) that would be too much for a condition that (IIRC) the datasheet says can happen. If that error is worse than causing a reboot then it might be the case that their emergency fix deployment might have the effect of causing problems by deploying never-actually-tested code into the wild. When I initially looked at this code before finding the flaw I was somewhat surprised that this test didn't produce spurious failures.
[Maybe someone who isn't traveling and on vacation might want to trace out that error condition, -- and check my vague recollection of the STM32 datasheets, as I could be remembering some other part]