Solo: device.c - add support for /dev/hwrng instead of /dev/urandom

[alphathegeek]

consider adding another parameter for RNG support, or checking if the developement platform has HWRNG support.

I use /dev/hidg0 on my Raspberry Pi for SoloKey Development, and since the Pi has a HW RNG, I'd like to use that as the RNG.

I patched "device.c" to use /dev/hwrng, instead of "/dev/urandom".

[nickray]

Thanks for bringing this up! Not being familiar with Raspberry Pis myself, do you have any evidence that urandom does not use the hwrng appropriately?

"Generally" (this is discussed all over the internet, e.g. https://www.2uo.de/myths-about-urandom/), Linux does "the right thing" to makeurandom the best possible (general purpose) CSPRNG on a given platform. So in this situation, I'd assume it uses hwrng, but possibly even more entropy sources. So in some sense, using hwrng directly might even be worse 😜.

Pull requests are certainly always welcome, in this case you just got me interested!

[nickray]

BTW, you may also be interested in https://github.com/solokeys/solo/issues/154, as there's a school of thought that distrusts blackbox embedded HWRNGs. Besides tests for "obvious" non-randomness, it seems quite hard to detect malfunctions and generally rate the quality of entropy sources.

[alphathegeek]

Good point. I do run "rngd" which supposedly ensures that urandom is seeded with a number of entropy sources, /dev/hwrng being one of them. So in that case, using /dev/urandom is probably the better option.

As an aside, I have a dedicated raspberry pi providing a source of randomness to the desktop PC, since the desktop uses another "black box" HWRNG provided by Intel, which I trust wayyy less.

The Pi Serves as my DIY "Solo-Hacker". About all the same issues as a "hacker" but without the ability to lock the bootloader, great for tooling around with though.

[alphathegeek]

I'd suggest closing this, since running on raspberrypi-zero is probably a corner case, and rngd confirmed running, so source of randomness is ok.