Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When random.bytes() runs but doesn't work

insider.btcpp.dev

Post reply on HN
Print view View original

21–30 of 63 posts

Re: When random.bytes() runs but doesn't work

#21

Post by dist-epoch »

londons_explore wrote: post #13

I am getting suspicious of "random number generator not actually returning random numbers" bugs.... They are the perfect bug for someone trying to "accidentally" make a secure system insecure. I wonder if bribe money was involved or three letter agencies...

And they waited 5 years to exploit it?

And do you think the NSA desperately needed $90 mil (the amount stolen so far), so they created this elaborate backdoor? Or were they waiting until Satoshi or Binance decided to deposit a billion dollars into this wallet?

All the employees which touched the code will be on watch lists now anyway. And sudden new house or yacht will be immediately flagged.

Re: When random.bytes() runs but doesn't work

#22

Post by dist-epoch »

nonfamous wrote: post #17

From 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.

Re: When random.bytes() runs but doesn't work

#23

Post by londons_explore »

dist-epoch wrote: post #21
londons_explore wrote: post #13

I am getting suspicious of "random number generator not actually returning random numbers" bugs.... They are the perfect bug for someone trying to "accidentally" make a secure system insecure. I wonder if bribe money was involved or three letter agencies...

And they waited 5 years to exploit it? And do you think the NSA desperately needed $90 mil (the amount stolen so far), so they created this elaborate backdoor? Or were they waiting until Satoshi or Binance decided to deposit a billion dollars into this wallet? All the employees which touched the code will be on watch lists now anyway. And sudden new house or yacht will be immediately flagged.

Need not be the NSA. Might just be some regular thief.

The longer they wait, the more they get to steal after all.

Re: When random.bytes() runs but doesn't work

#24

Post by dist-epoch »

nullc wrote: post #9

This 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…

I wonder if some sort of "taint" analysis could be used - you generate a byte of randomness and trace it back through code until you see all the sources of entropy which were used as input.

Hard problem in general, but with LLMs surely this is possible now, either with them inspecting or by them providing some sort of "formal" proof - this function calls this function which reads this buffer which gets input from here...

Re: When random.bytes() runs but doesn't work

#25

Post by josephg »

dist-epoch wrote: post #21
londons_explore wrote: post #13

I am getting suspicious of "random number generator not actually returning random numbers" bugs.... They are the perfect bug for someone trying to "accidentally" make a secure system insecure. I wonder if bribe money was involved or three letter agencies...

And they waited 5 years to exploit it? And do you think the NSA desperately needed $90 mil (the amount stolen so far), so they created this elaborate backdoor? Or were they waiting until Satoshi or Binance decided to deposit a billion dollars into this wallet? All the employees which touched the code will be on watch lists now anyway. And sudden new house or yacht will be immediately flagged.

> And do you think the NSA desperately needed $90 mil (the amount stolen so far)

If this was done as part of an operation, we would have no idea what it was actually used for. It’s very unlikely that the crypto wallet thefts we know about were the intended target.

Re: When random.bytes() runs but doesn't work

#26

Post by hypeatei »

> 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 don't know why anyone would keep their wealth in something that requires so much technical excellence.

Re: When random.bytes() runs but doesn't work

#27

Post by egwor »

nullc wrote: post #9

This 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…

Although I might disagree with the style of the write up, I think it is right that there are weak engineering practices applied:

- not enough information provided in commit message. - this change ought to have been split into smaller chunks (e.g. introduce indirection whilst code continues to use hardware) - limited (automated) testing - potential confusion by the author over C concepts - additional complexity which could have been hidden behind a cleaner interface rather than using defines

I agree about your points about:

- defines over multiple repo's made this more complicated that was necessary. - fault injections would have been the appropriate way to test this (or maybe mocks) - testing of randomness needs careful design, e.g. RNG seeding can be a good way

Taking a step back, we as a community of excellence need to emphasise that this isn't a criticism about the person/author. There needs to be a clear analysis of what went wrong whilst being kind to the person/people involved.

Re: When random.bytes() runs but doesn't work

#28

Post by koolba »

> A good goal as a developer is a high commit message to change ratio. The more lines of code that you change, the more comments explaining why you’re changing the code. More message and less code changes per commit is generally a good idea.

No! Blanket statements like this is how you end up with 40 pages of slop AI comments in PRs that nobody reads.

Comments should be terse and meaningful. They should document surprising behavior or choices. The less comments you have, the more meaningful each one becomes because your time and eyeballs are limited as well.

Re: When random.bytes() runs but doesn't work

#29

Post by inigyou »

silvestrov wrote: post #19
anonymousiam wrote: post #2

This post assumed that the author of the "runs" commit was not acting maliciously. Has that been established? It's not mentioned in this article.

When looking through all the other commits the user has made: they all lack a good commit message. This is systematic for that user. Either the user needs to improve or let go. The organization needs to learn that good commit messages are a requirement for anything to do with crypto and payment systems.

The commit message is just a surface level manifestation of a deeper issue. Fixing the commit message does not fix the issue.

Re: When random.bytes() runs but doesn't work

#30

Post by inigyou »

nullc wrote: post #9

This 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…

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.
Post reply on HN