On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote: > I was thinking along the lines that "almost every important package > supports FreeBSD as well where they have to handle the condition so > option to switch to Rather Break Than Generate Weak Keys would be nice" > - but I didn't expect that systemd could be a roadblock here. :-/ It wasn't just systemd; it also broke OpenWRT and Ubuntu Quantal systems from booting. > I was also thinking of little devices where OpenWRT or proprietary > Linux-based systems run that ended up with predictable keys way too > ofter (or as in OpenWRT's case, with cumbersome tutorials how to > generate keys elsewhere). OpenWRT and other embedded devices (a) generally use a single master oscillator to drive everything, and (b) often use RISC architectures such as MIPS. Which means that arguments of the form ``the Intel L1 / L2 cache architecture is ****soooo**** complicated that no human could possibly figure out how they would affect timing calculations, and besides, my generator passes FIPS 140-2 tests (never mind AES(NSA_KEY, CNTR++) also passes the FIPS 140-2 statistical tests)'' --- which I normally have trouble believing --- are even harder for me to believe. At the end of the day, with these devices you really badly need a hardware RNG. We can't generate randomness out of thin air. The only thing you really can do requires user space help, which is to generate keys lazily, or as late as possible, so you can gather as much entropy as you can --- and to feed in measurements from the WiFi (RSSI measurements, MAC addresses seen, etc.) This won't help much if you have an FBI van parked outside your house trying to carry out a TEMPEST attack, but hopefully it provides some protection against a remote attacker who isn't try to carry out an on-premises attack. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
