Thread on debian-devel "Handling of entropy during boot".

"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." - Theodore Y. Ts'o

source: lists.debian.org/debian-devel/

Given popularity of RPi in bitcoin (nodes), this is concerning to realize.

Follow

Make sure to check out the whole post (and/or thread)

That was in Dec 2018 and thread continues in Jan 2019 here:
lists.debian.org/debian-devel/

There is a bcm2708-rng.ko kernel module you can load and if you use rng-tools or rng-tools5 package*, that'll greatly improve the entropy pool.
I don't know if that would be good entropy (or whether there is such a thing as good/bad entropy) as that is outside my area of expertise.

*) in Debian Stable. For testing/Sid it's rng-tools-debian/rng-tools5

Never expected that there would be so much to read/learn about randomness 😮

In the previously mentioned thread there was also a link to daniel-lange.com/archives/152- which in turn led me to bugs.debian.org/cgi-bin/bugrep

"Starting with the 3.17 kernel, the kernel will automatically pull from
hardware random number generators without needing to install a user space daemon, such as rng-tools."

But it comes with a caveat which I'm not fully getting (follow the link, as I don't have enough chars left here)

@FreePietje the usual caveat with Real RNGs is that there's no practical way to audit them to ensure they give good randomness. It's quite believable that the NSA will backdoor a production RRNG to compromise all our cryptography. That just means you can't *depend* on RRNGs; you can still combine their entropy with a known-good source of entropy to get a result that's at least as strong as the strongest contributed entropy.

@harding
What I gathered from Ts'o's remarks is that basically every user has to decide for themselves which devices to trust and "X.rng_quality=Y" kernel parameter seems to indicate you also need to know how good a HWRNG is.
Theodore's reasoning is quite logical, but I'm guessing unfeasible for 99% of 'normal' people.
I happen to know of it, but I can't say that I (really) understand it.

In general terms yes, but not details and they seem to matter quite a bit.

@harding
I'm (also) assuming that NSA/Intel has backdoored the HWRNG in their CPUs and glad that Ts'o had that foresight to only mix it in with the rest.
I also learned about Chaos Key (shop.gag.com/random/chaoskey.h) which seems to be a Open Hardware RNG, which in turn was the idea behind 'specifying' RISC-V in my other toot

@FreePietje Nah, rng_quality just says how the entropy is used. High quality sources are used directly. Low-quality sources are put into the entropy pool to be mixed with each other and then mixed with a high-quality source before being used directly.

I only skimmed Ts'o's post, but that mainly seems to be about the random seed file, which is a problem on SBCs and also VMs. I thought his overall point was: if waiting for entropy causes long startup times, learn patience or expect regret.

@harding
He mentioned RPi multiple times as the hardware makes it very hard for the kernel to *gather* entropy. VMs have indeed a similar problem but that can be worked around (it seems).

But it turned into a real problem icw systemd (surprise :P) as it killed daemons due to timeouts as it just took to long (for systemd)

The random seed file was another/different issue where he (rightfully) questioned whether it could be relied upon, even for a bit.

@FreePietje @harding The random-seed file's purpose is to retain entropy between boots. Any reading of the file after booting is foolish (though writing to it before shutdown can make the system more robust against power loss, which I'm surprised by that is not considered relevant enough to implement).

@kekcoin @harding
Do read (all) the posts regarding this on debian-devel (spread over multiple months). I'm quite sure they discussed this.
After reading that I realized that randomness was far more complex then I ever realized. That's also why I prefer to refer to that thread then try to summaries the things that I still remember.

@FreePietje @harding Will do, thanks. It's a bit out of scope for my current project due to time constraints, but I am interested in distilling the wisdom from these kinds of discussions into a "hardening raspi setup" guide.

@harding
My issue/confusion is that I have no clue what a/the proper value for rng_quality would be. Or even what (devices) can be qualified as high quality.

F.e. for the HWRNG in the RPi, I wouldn't be able to answer either question.

I would have the same issue with any other RNG and I'm guessing I'm not the only one.
However well reasoned Ts'o's argument is, I fear it's not really workable (unless you're well versed in cryptography).

Sign in to participate in the conversation
unidentified instance

swarm ops (instance image by мøтħer ¢røω)