[OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
smueller at chronox.de
Sat May 25 12:42:19 PDT 2019
Am Samstag, 25. Mai 2019, 12:43:25 CEST schrieb Etienne Champetier:
> Hi Petr,
> 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
> missing something
> 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]:
> > 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).
> > 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
Well, some libraries still use /dev/urandom and are not blocked. Besides, if
you use systemd that initializes the system, it uses /dev/urandom. Compile
your kernels with CONFIG_WARN_ALL_UNSEEDED_RANDOM, you will see kernel reports
which processes seed from /dev/urandom even while it is not fully provided
> > > 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
> > 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/bb5530e4082446aac3a3d69780cd4db
> > > fa4520013>
> > 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
> behave differently
> Is the kernel module underestimating entropy ? Is you user space
> version over estimating entropy ?
Again, the in kernel version is *only* used for seeding the in-kernel DRBG
(unfortunately). This DRBG and the in-kernel Jitter RNG has no relationship
with /dev/random or /dev/urandom or getrandom. You could call the in-kernel
DRBG with AF_ALG like libkcapi allows you to do .
If you are interested, I wrote a complete replacement implementation of the
current /dev/random or /dev/urandom available at . It uses the in-kernel
Jitter RNG, it has pluggable PRNGs and other logic relevant for, say, FIPS
140-2. This implementation would not require you to have your separate user
space entropy daemon that is discussed here. Yet, this code was rejected.
More information about the openwrt-devel