3 ms·
No it isn't the entire issue. Or more precisely on your average desktop system this isn't really a problem. The jitter dance will suffice here. The clue is in
by zahllos 5y ago
No it isn't the entire issue. Or more precisely on your average desktop system this isn't really a problem. The jitter dance will suffice here.
The clue is in randomness seed files. You won't have one of these on a PC because you don't need it. Once you have your 128/256 bits of entropy you can stretch this using a DRBG for actual use and it'll be good.
The problem is systems that are much more deterministic, because they have simpler CPUs that don't do speculative execution, or have anything fancy by way of caching. Their peripherals are fixed at boot time via a devicetree file and udev style peripheral plug and play doesn't happen.
These tend to be embedded use cases. To get around this, you have a seed file to give you at least some good entropy. Then you mix in the best you can get and update that seed file for next boot. Hopefully this plus what you get while the device is on is enough for next time.
A lot of crypto including the tls you might use to get stuff off the internet will break if the quality of randomness is not good enough.
You are reading 'Linux' and hearing 'desktop' but the reality is there is a lot more embedded Linux than desktop Linux, and that's where the entropy problems start to creep in depending on the device in question.
- Sharlin 5y ago> You are reading 'Linux' and hearing 'desktop' but the reality is there is a lot more embedded Linux than desktop Linux Yeah, this is a weird example of availability bias. Of the literally billions of Linux instances on the planet, how many are desktops these days? One in a thousand? Even less? Most of them are Android phones, most of the rest (other) embedded devices, almost all of the rest, servers.