I just noticed that upon installing rng-tools, the default package urngd still has its daemon enabled and running. Shouldn't they conflict somehow?
# ps aux | grep rng
rngd 1265 0.0 0.0 11680 4784 ? S 19:47 0:00 /sbin/rngd -D rngd:rngd -f -r /dev/hwrng
root 1324 0.0 0.0 10888 1716 ? S 19:47 0:00 /sbin/urngd
No , it should not.
That doesn't seem right. As far as I can tell, they are the same software. rngd is just a newer version.
Although I’m not sure either are needed post 5.something, as the changes Jason Donenfeld put in should - in most cases - mean the kernel is self sufficient: https://www.zx2c4.com/projects/linux-rng-5.17-5.18/
jitterentropy self-test fails (that kernel you refer to…) on ramips, you can use haveged to compensate.
Okay, but then inclusion should be architecture dependent.
Just that your article does not cover all cracks. Including prominently visible ones.
The prominent example is an arch that’s been aging out for some time ? The trouble is the mechanism used in both cases - timing jitter - is the same (ignoring hwrngs which are rare on these devices). So either it could work – in which case the fix needs to ideally be upstreamed in the kernel or it doesn’t, in which case rng/havged etc are just adding a false sense of security.
But in cases where it works it’s going to be better to have one clear auditable mechanism, rather than an interaction between multiple mechanisms, some opaque.