[OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
champetier.etienne at gmail.com
Sat May 25 06:43:25 EDT 2019
Just to be clear i'm 100% in favor of your effort to have random pool
init done fast on all devices,
and your solution, based on Stephan awsome work, seems really good
I just want to be sure we don't make some devices worse / are not
Le mar. 21 mai 2019 à 16:55, Petr Štetiar <ynezz at true.cz> a écrit :
> Etienne Champetier <champetier.etienne at gmail.com> [2019-05-21 14:55:42]:
> > > 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).
> i.mx6 (Freescale i.MX6 Quad/DualLite)
> [ 3.281637] random: fast init done
> [ 1120.394672] random: crng init done (yeah, 18 minutes)
I'm not saying it's not happening, I'm wondering if the boot process
is not blocked early by a process stuck on getrandom()
and then nothing runs on router so no entropy is produced, so the
process continue to be stuck
> > 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 to save it during EVERY shutdown, so it's
> different EVERY boot.
I know and I'm in favour of it, but proper shutdown is not always a
thing on router, that is why I went with getrandom() at the time
> * 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.
Starting on second boot, we are sure each router state is different,
but each boot are pretty similar I agree
> > 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
> > (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
> > 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 think before anyone merge this (I'm not a core dev), we need to
explain why your user space version and the kernel module version
Is the kernel module underestimating entropy ? Is you user space
version over estimating entropy ?
> > 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 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
> 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 at lists.openwrt.org
More information about the openwrt-devel