Etienne Champetier <champetier.etie...@gmail.com> [2019-05-21 14:55:42]:
Hi, > > First, simply writing to /dev/urandom does not increase the kernel's > > entropy count, this casuses processes obtaining randomness to block. > > Particularly processes using OpenSSL's RAND_bytes() will block until the > > kernel emits 'random: crng init done'. This can take upwards of twenty > > minutes. > > 20 minutes seems excessive, isn't one of the process blocking boot ? please note, that this is time as measured by kernel (I know it's userspace starving the kernel entropy pool, but still). I've personally measured 18 minutes on my Apalis board (imx6)[1]. i.mx6 (Freescale i.MX6 Quad/DualLite) [ 3.281637] random: fast init done [ 1120.394672] random: crng init done (yeah, 18 minutes) > One of the issue is that if you try to generate a new seed, you are > just reading a hash of the seed you injected seconds earlier with > maybe few new bits of entropy Exactly, that's why it's recommended[2] to save it during EVERY shutdown, so it's different EVERY boot. * Ensuring unpredictability at system startup * ============================================ * * When any operating system starts up, it will go through a sequence * of actions that are fairly predictable by an adversary, especially * if the start-up does not involve interaction with a human operator. * This reduces the actual number of bits of unpredictability in the * entropy pool below the value in entropy_count. In order to * counteract this effect, it helps to carry information in the * entropy pool across shut-downs and start-ups. [...] * Even with complete knowledge of the start-up activities, predicting the * state of the entropy pool requires knowledge of the previous history of the * system. We're making it easier for the potential adversary, aren't we? We're currently feeding static urandom.seed file (generated during first boot) to kernel every other boot, in some cases it might result in the same file for the lifetime of the device. I really miss any randomness in this. > Just for the record, this is the default setting, I know, that's why I'm proposing removal from the default ath79 images, because I think, that it's wrong. Should the user ever need urandom-seed, then it's just one opkg install away. > you can change your config to generate a new one at each boot I know, but who does it? I expect best possible secure configuration by default. > (the worry was that we would wear off the flash too fast) I understand the drawbacks, that's why I think, that it doesn't make much sense to use it, if it's not good enough to be used in default/shipped configuration. > why not use jitterentropy RNG that is in kernel since 4.2 ? > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013 I started experiments with kmod-crypto-rng package which already contains jitterentropy, drbg, krng and rng kernel modules, but it didn't improved the long booting times for me on ath79. Other reason was size of this kernel module(s) as they provide much more functionality of course. > I haven't had time to read all the papers from Stephan Muller, but I > don't know how safe & tested Jitter RNG is on ALL architectures I've based urngd on Jitter NPTRNG simply because Stephan did amazing work with testing[3] and analysis of embedded CPUs as well. I couldn't say the same about other solutions I've considered, like haveged for example. Bonus points for being in the kernel since 2015, which makes me quite confident, that it should work somehow on everything kernel runs on. > For example this comment doesn't inspire me > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013#diff-8e0798e05c8dca3aa9007504c87cee73R125 > > If random_get_entropy does not return a value (which is possible on, > > for example, MIPS), invoke __getnstimeofday > > hoping that there are timers we can work with. (That's exactly why I took the liberty and added Stephan to the Cc: list of this email, so he could provide his input on this matters or other matters) To me it just shows, that the implementation isn't naive and went through some rounds of testing which apparently spotted some corner cases on some CPUs, like for example this one: F.31 MIPS 4KEc V4.8 (T-Com Speedport W701V) ... Figure 120 ... the Shannon Entropy concludes that the CPU execution time jitter on this CPU is too small. The reason for that is the coarse counter which increments in multiples of 1,000. --> However, the good news is that on this CPU, the jent_entropy_init(3) call would fail, informing the caller about to not use the CPU Jitter random number generator. So urngd with Jitter NPTRNG should hopefully provide good enough entropy or none at all. 1. https://patchwork.ozlabs.org/patch/1056981/#2113014 2. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n231 3. http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html (Section F.) -- ynezz _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
