Is it advisable to generate WireGuard public/private keys on embedded devices, or is there generally not enough entropy?
It depends...
In general embedded, headless or non-interactively used/ remotely accessed devices do have a hard time gathering (high quality) entropy. Some SOCs or wlan combinations mitigate this by providing a hardware rng facility of some sorts, albeit not all of good quality, e.g. ath5k/ ath9k wlan cards do derive entropy from wifi noise (not that random, but better than nothing, if mixed well by the kernel and not used directly) - others like ath10k or mwlwifi do not contribute to the entropy pool.
With recent kernels, you do tend to getter better entropy, but at the expense of long blocking calls to /dev/random, meaning at least the quality should be o.k. (assuming seeding the rng properly), if you dare to wait and not take too many short cuts. If you know what you're doing, generating cryptographic certificates and keys on an interactively used desktop with lots of 'random' events (e.g. mouse movements) and other 'noise' will yield better results, but if you don't know what you're doing when copying these keys around (file access permissions, leaving keys around in multiple places, etc.), then doing it on the entropy starved target device might still be a safer choice.
2 Likes
Consider haveged - it's in the repos...
But that doesn't solve /dev/random running out and blocking...
Agreed - also consider VM's, where getting good inputs can be a challenge...