this is a good detailed write-up about developments in bitcoin-core's build system security which i missed the first time around
I didn't know 'you' had your own internal RNG.
Does this mean that if the RNG on a RPi isn't (very) good, that it has no or only a marginal effect on the randomness used by bitcoin?
Theodore Ts'o raised some concerns wrt that.
@FreePietje right we added some fallbacks on top of the operating system's randomness
kind of a defense in depth strategy because randomness is more important to bitcoin than most applications—at least for generating wallets
all these are mixed together:
- hardware randomness (e.g. special CPU instructions)
- operating system randomness (e.g. urandom)
- context "randomness" (timings, process context information)
@FreePietje that said, it's a mitigation, if everything in your environment is entirely deterministic (e.g. a VM or bare-bones embedded system) it cannot 100% protect against bad randomness
It indeed very much makes sense.
Ts'o concerns were/are a major reason why I think RPi's are (fun, but) ultimately not suitable as bitcoin nodes. RPi's are still lacking in sources for randomness and Broadcom not licensing armv8 crypto extensions isn't helping, but it's good/cool that bitcoin is at least trying to mitigate against such things.
I can't find my toot-thread I did about this (maybe other instance?), but iirc the main problem was a missing reliable clock source. I don't know if a RTC HAT would fix that.
ESR had a project in which he was trying to turn a RPi into a Stratum 1 server, but I don't know what the latest is on that. ESR is also the main architect of NTPsec.
"quite frankly Rasberry PI's are extremely problematic devices from a security perspective. They use a coarse-grained clock, so it's very hard to get good entropy out of timing events, and very the hardware that they have on them is such that there aren't many events that we can use to
generate entropy in the first place."
@FreePietje @kekcoin definitely true that a course-grained clock can make collecting entropy from i/o events harder—it doesn't need a RTC though, because relative precision is important, but not wall clock time—commonly though something like the CPU's own cycle clock is used for this
(i admit not really knowing how this works on ARM)
Seeing my join date here and the date of the start of that thread, I likely did post about it on this account/instance. But (apparently) I didn't use hashtags back then.
I don't feel like scrolling through all my history to find it again though ;) 😂
@roshii @FreePietje from what i understand from that page, it reads random bytes from the card and feeds them to the kernel's entropy pool—so it will benefit any program using [u]random, including bitcoin core
(which is good because it's a non-starter to add something specific like that to the dependency base)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!