Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Hi Petr, Le lun. 27 mai 2019 à 10:00, Petr Štetiar a écrit : > > Etienne Champetier [2019-05-25 12:43:25]: > > > 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 > > FYI, I've just added more devices to the testing before submitting the next > round of patches, and got following on the MT7620A based device: > > root@OpenWrt:/# cat /proc/cpuinfo > system type : MediaTek MT7620A ver:2 eco:6 > machine : BDCOM WAP2100-SK > processor : 0 > cpu model : MIPS 24KEc V5.0 > > root@OpenWrt:/# cat > /sys/devices/system/clocksource/clocksource0/available_clocksource > systick MIPS > > root@OpenWrt:/# /sbin/urngd > jent-rng init failed, err: 2 > > Where that error 2 is ECOARSETIME. It makes me wonder if there's something > which could be tweaked on kernel side in order to provide better environment > for jent-rng on this quite still popular SoC. The fact that missing high precision timer is properly detected is a good news, but now that means you really need to provide a fallback, else removing urandom-seed is a regression > > -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Am Montag, 27. Mai 2019, 15:00:23 CEST schrieb Petr Štetiar: Hi Petr, > Etienne Champetier [2019-05-25 12:43:25]: > > 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 > > FYI, I've just added more devices to the testing before submitting the next > round of patches, and got following on the MT7620A based device: > > root@OpenWrt:/# cat /proc/cpuinfo > system type : MediaTek MT7620A ver:2 eco:6 > machine : BDCOM WAP2100-SK > processor : 0 > cpu model : MIPS 24KEc V5.0 > > root@OpenWrt:/# cat > /sys/devices/system/clocksource/clocksource0/available_clocksource systick > MIPS > > root@OpenWrt:/# /sbin/urngd > jent-rng init failed, err: 2 > > Where that error 2 is ECOARSETIME. It makes me wonder if there's something > which could be tweaked on kernel side in order to provide better environment > for jent-rng on this quite still popular SoC. The Jitter RNG is dependent on the existence of a high-resolution timer. The mentioned system does not seem to have one. Check /sys/devices/system/clocksource/clocksource0/current_clocksource and / sys/devices/system/clocksource/clocksource0/available_clocksource Ciao Stephan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Etienne Champetier [2019-05-25 12:43:25]: > 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 FYI, I've just added more devices to the testing before submitting the next round of patches, and got following on the MT7620A based device: root@OpenWrt:/# cat /proc/cpuinfo system type : MediaTek MT7620A ver:2 eco:6 machine : BDCOM WAP2100-SK processor : 0 cpu model : MIPS 24KEc V5.0 root@OpenWrt:/# cat /sys/devices/system/clocksource/clocksource0/available_clocksource systick MIPS root@OpenWrt:/# /sbin/urngd jent-rng init failed, err: 2 Where that error 2 is ECOARSETIME. It makes me wonder if there's something which could be tweaked on kernel side in order to provide better environment for jent-rng on this quite still popular SoC. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Am Sonntag, 26. Mai 2019, 14:47:33 CEST schrieb Petr Štetiar: Hi Petr, > > could you please point me to that email thread? What's your plan now? Do you > simply plan to maintain it as out of tree kernel module forever or do you > plan to eventually address the comments leading to the reject and try it > again later? I will maintain it out of tree as it is an interesting project to me considering that entropy and cryptography are my hobbies. If you want to search for the discussions as there are many considering the fact that I supplied several versions, search for "Linux /dev/random - a new approach". Ciao Stephan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Stephan Müller [2019-05-25 21:42:19]: Hi, > If you are interested, I wrote a complete replacement implementation of the > current /dev/random or /dev/urandom available at [2]. 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. the main reason for urngd was size, because I plan to have it included in all default firmware images, even for tiny devices with 4MiB of flash space. The kernel machinery is more heavy as it have more features. > Yet, this code was rejected. could you please point me to that email thread? What's your plan now? Do you simply plan to maintain it as out of tree kernel module forever or do you plan to eventually address the comments leading to the reject and try it again later? Thanks a lot for your great work! > [1] http://www.chronox.de/libkcapi.html > [2] http://www.chronox.de/lrng.html Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Etienne Champetier [2019-05-25 12:43:25]: Hi, > I just want to be sure we don't make some devices worse / are not > missing something and I really appreciate that, the more eyes, the better. > > Exactly, that's why it's recommended[2] 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 Indeed, and I think, that it served us well. Now, that we've found out, that it's not helping that much as it was expected, and having proper source of randomness, we could simply stop using it in default install. Should you still need it, you can `opkg install` it back. > > 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), This is just an RFC, so I'm not going to merge it anyway. I'm going to post another series of patches without the RFC and I plan to merge it myself if I get Acked-by from at least one additional core developer. I find this part of the system important enough, that I'm not going to push it myself. My current plan for the new series is following: * enable CONFIG_WARN_ALL_UNSEEDED_RANDOM by default in all kernels * add urngd as default package, because it's going to improve the overall system randomness * start urngd directly in procd to get rid of the following warnings: random: procd: uninitialized urandom read (4 bytes read) procd: - ubus - random: ubusd: uninitialized urandom read (4 bytes read) random: ubusd: uninitialized urandom read (4 bytes read) random: ubusd: uninitialized urandom read (4 bytes read) procd: - init - * create packages for urandom-seed, getrandom and remove those from the default images > 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 ? I hope, that Stephan has already provided that answer in the other email to you. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Am Samstag, 25. Mai 2019, 12:43:25 CEST schrieb Etienne Champetier: Hi Etienne, > 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 a écrit : > > Etienne Champetier [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) > > 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 with entropy. > > > > 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. > > 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).
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Am Montag, 20. Mai 2019, 18:13:20 CEST schrieb Petr Štetiar: Hi Petr, A system called TNT BOM BOM sent me test results for Qubes. I am not sure who to reply to the analysis. Therefore, I will reply to this thread. The first test "Test-Results" show that the heuristic validating whether the underlying platform is sufficient for the Jitter RNG has detected no insufficiency during 1 test runs. Check. The file foldtime.O0 contains test results for the non-optimized binary code that is the basis for the Jitter RNG. To understand what it shows, we have to understand what the Jitter RNG really does: it simply measures the execution time of a fixed code fragment. The test does the same, i.e. it measures what the Jitter RNG would measure. Each time delta is simply recorded. Each time delta is expected to contribute entropy to the entropy pool. But how much? We can use the SP800-90B tool set provided by NIST at [1]. This tool, however, can only process input data with a window size of a few bits at most. Thus, we take the 4 LSB of each time delta, hoping that they contain already sufficient entropy. Using the tool [1], we get the following output: Running non-IID tests... Running Most Common Value Estimate... Bitstring MCV Estimate: mode = 2005620, p-hat = 0.501404999, p_u = 0.50204895486400081 Most Common Value Estimate (bit string) = 0.994100 / 1 bit(s) Running Entropic Statistic Estimates (bit strings only)... Bitstring Collision Estimate: X-bar = 2.5010973564651491, sigma-hat = 0.4895212561996, p = 0.5 Collision Test Estimate (bit string) = 1.00 / 1 bit(s) Bitstring Markov Estimate: P_0 = 0.501404999, P_1 = 0.498595001, P_0,0 = 0.5003230926766, P_0,1 = 0.4996769073234, P_1,0 = 0.50249325729964067, P_1,1 = 0.49750674270035933, p_max = 3.86818991019963e-39 Markov Test Estimate (bit string) = 0.996903 / 1 bit(s) Bitstring Compression Estimate: X-bar = 5.2170320393664023, sigma-hat = 1.0146785561878935, p = 0.025847044943319686 Compression Test Estimate (bit string) = 0.878976 / 1 bit(s) Running Tuple Estimates... Bitstring t-Tuple Estimate: t = 18, p-hat_max = 0.52360109960331436, p_u = 0.52424433922577907 Bitstring LRS Estimate: u = 19, v = 42, p-hat = 0.50001215824001477, p_u = 0.50065611564620627 T-Tuple Test Estimate (bit string) = 0.931689 / 1 bit(s) LRS Test Estimate (bit string) = 0.998108 / 1 bit(s) Running Predictor Estimates... Bitstring MultiMCW Prediction Estimate: N = 337, Pglobal' = 0.50046008453798463 (C = 1999233) Plocal can't affect result (r = 24) Multi Most Common in Window (MultiMCW) Prediction Test Estimate (bit string) = 0.998673 / 1 bit(s) Bitstring Lag Prediction Estimate: N = 399, Pglobal' = 0.50117058226135014 (C = 2002106) Plocal can't affect result (r = 22) Lag Prediction Test Estimate (bit string) = 0.996626 / 1 bit(s) Bitstring MultiMMC Prediction Estimate: N = 398, Pglobal' = 0.50240995443366221 (C = 2007063) Plocal can't affect result (r = 21) Multi Markov Model with Counting (MultiMMC) Prediction Test Estimate (bit string) = 0.993063 / 1 bit(s) Bitstring LZ78Y Prediction Estimate: N = 383, Pglobal' = 0.50195008712868949 (C = 2005216) Plocal can't affect result (r = 24) LZ78Y Prediction Test Estimate (bit string) = 0.994384 / 1 bit(s) h': 0.878976 - as we analyzed 4 bits of each time delta, we get 4 * 0.878976 = 3.515904 bits of entropy per four bit time delta - assuming the worst case that all other bits in the time delta have no entropy, we have 3.515904 bits of entropy per time delta - the Jitter RNG gathers 64 time deltas for returning 64 bits of random data and it uses an LFSR with a primitive and irreducible polynomial which is entropy preserving. Thus, the Jitter RNG collected 64 * 3.515904 = 225.017856 bits of entropy for its 64 bit output. - as the Jitter RNG maintains a 64 bit entropy pool, its entropy content cannot be larger than the pool itself. Thus, the entropy content in the pool after collecting 64 time deltas is max(64 bits, 225.017856) = 64 bits This implies that the Jitter RNG data has (close to) 64 bits of entropy per data bit. Bottom line: When the Jitter RNG injects 64 bits of data into the Linux /dev/ random via the IOCTL, it is appropriate that the entropy estimator increases by 64 bits. Bottom line: From my perspective, I see no issue in using the Jitter RNG as a noise source in your environments. Note, applying the Shannon-Entropy formula to the data, we will get much higher entropy values. Note II: This assessment complies with the entropy assessments to be done for a NIST FIP 140-2 validation compliant to FIPS 140-2 IG 7.15 [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment Ciao Stephan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
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 a écrit : > > Etienne Champetier [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) 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[2] 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/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 behave differently Is the kernel module underestimating entropy ? Is you user space version over estimating entropy ? Regards Etienne > > > 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
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Am Dienstag, 21. Mai 2019, 16:55:02 CEST schrieb Petr Štetiar: Hi Petr, > Etienne Champetier [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. It is not correct to have a static seed file. But on the other hand, this seed file is intended to mix the entropy pool only. It is credited with no entropy. > > > 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/bb5530e4082446aac3a3d69780cd4dbfa > > 4520013 > 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. The Jitter RNG is intended to be used in the environment where it is needed. Having multiple instances is even good for the entropy over all. Thus, I think using a user space copy is the right thing to do. > > > 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. Well, it survived a number of FIPS 140-2 validations and the associated entropy assessment requirements as well :-) > > > For example this comment doesn't inspire me > > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa > > 4520013#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) The issue is that the Jitter RNG rests on the presence of a high-resolution timer. The Jitter RNG implements a startup test that is intended to detect
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Etienne Champetier [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.
Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Hi Petr, Le lun. 20 mai 2019 à 18:14, Petr Štetiar a écrit : > > Hi, > > this patch series is an RFC which attempts to fix some of the current > urandom-seed based flaws. > > 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 ? > > According to random(4) the entropy count is only increased when using the > RNDADDENTROPY ioctl, which urandom-seed currently doesn't use when feeding the > kernel RNG. we could use RNDADDENTROPY, but as I'm no cryptographer, I just imitated what was done in debian before systemd and in systemd at the time (read a seed when random pool is initialized, feed it on next boot) 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 > > Second, urandom-seed is using /etc/urandom.seed file to seed the kernel's RNG > machinery upon every boot. The problem is, that this file is created only once > during first-boot and then reused on every consecutive boot, so pretty much > static. Just for the record, this is the default setting, you can change your config to generate a new one at each boot (the worry was that we would wear off the flash too fast) > > So this patch series removes urandom-seed package in favor of urngd, which is > new micro non-physical true random number generator (system service) based on > timing jitter. Having a seed file never hurts, so I would keep it > > Using the Jitter RNG core, the urngd provides an entropy source that > feeds into the Linux /dev/random device if its entropy runs low. It > updates the /dev/random entropy estimator such that the newly provided > entropy unblocks /dev/random. > > The seeding of /dev/random also ensures that /dev/urandom benefits from > entropy. Especially during boot time, when the entropy of Linux is low, > the Jitter RNGd provides a source of sufficient entropy. why not use jitterentropy RNG that is in kernel since 4.2 ? https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013 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 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. Regards Etienne > > > Some RNG init time numbers from qca9563 (TP-Link Archer C7 v5): > > [ 12.045693] random: crng init done(urngd) > [ 120.043132] random: crng init done(urandom-seed) > > Flash space details: > > urngd:+ 4579 b > getrandom:- 1635 b > urandom-seed: - 841 b > -- > diff + 2103 b > > Cc: Stephan Mueller > Cc: Dustin Lundquist > > Petr Štetiar (5): > urng: add micro non-physical true RNG based on timing jitter > ubox: move getrandom into separate getrandom package > base-files: move urandom seed bits into separate package > build: add urandom-seed to the default packages set > ath79: make urngd default RNG seed source > > include/target.mk | 2 +- > package/base-files/Makefile| 11 - > package/base-files/files/etc/init.d/urandom_seed | 12 -- > .../base-files/files/lib/preinit/81_urandom_seed | 24 --- > package/base-files/files/sbin/urandom_seed | 20 - > package/system/ubox/Makefile | 17 ++-- > package/system/urandom-seed/Makefile | 32 +++ > .../urandom-seed/files/etc/init.d/urandom_seed | 12 ++ > .../urandom-seed/files/lib/preinit/81_urandom_seed | 24 +++ > .../system/urandom-seed/files/sbin/urandom_seed| 20 + > package/system/urngd/Makefile | 48 > ++ > package/system/urngd/files/urngd.init | 21 ++ > target/linux/ath79/Makefile| 3 +- > 13 files changed, 184 insertions(+), 62 deletions(-) > delete mode 100755 package/base-files/files/etc/init.d/urandom_seed > delete mode 100644 package/base-files/files/lib/preinit/81_urandom_seed > delete mode 100755 package/base-files/files/sbin/urandom_seed > create mode 100644 package/system/urandom-seed/Makefile > create mode 100755 package/system/urandom-seed/files/etc/init.d/urandom_seed > create mode 100644 > package/system/urandom-seed/files/lib/preinit/81_urandom_seed > create mode 100755
[OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter
Hi, this patch series is an RFC which attempts to fix some of the current urandom-seed based flaws. 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. According to random(4) the entropy count is only increased when using the RNDADDENTROPY ioctl, which urandom-seed currently doesn't use when feeding the kernel RNG. Second, urandom-seed is using /etc/urandom.seed file to seed the kernel's RNG machinery upon every boot. The problem is, that this file is created only once during first-boot and then reused on every consecutive boot, so pretty much static. So this patch series removes urandom-seed package in favor of urngd, which is new micro non-physical true random number generator (system service) based on timing jitter. Using the Jitter RNG core, the urngd provides an entropy source that feeds into the Linux /dev/random device if its entropy runs low. It updates the /dev/random entropy estimator such that the newly provided entropy unblocks /dev/random. The seeding of /dev/random also ensures that /dev/urandom benefits from entropy. Especially during boot time, when the entropy of Linux is low, the Jitter RNGd provides a source of sufficient entropy. Some RNG init time numbers from qca9563 (TP-Link Archer C7 v5): [ 12.045693] random: crng init done(urngd) [ 120.043132] random: crng init done(urandom-seed) Flash space details: urngd:+ 4579 b getrandom:- 1635 b urandom-seed: - 841 b -- diff + 2103 b Cc: Stephan Mueller Cc: Dustin Lundquist Petr Štetiar (5): urng: add micro non-physical true RNG based on timing jitter ubox: move getrandom into separate getrandom package base-files: move urandom seed bits into separate package build: add urandom-seed to the default packages set ath79: make urngd default RNG seed source include/target.mk | 2 +- package/base-files/Makefile| 11 - package/base-files/files/etc/init.d/urandom_seed | 12 -- .../base-files/files/lib/preinit/81_urandom_seed | 24 --- package/base-files/files/sbin/urandom_seed | 20 - package/system/ubox/Makefile | 17 ++-- package/system/urandom-seed/Makefile | 32 +++ .../urandom-seed/files/etc/init.d/urandom_seed | 12 ++ .../urandom-seed/files/lib/preinit/81_urandom_seed | 24 +++ .../system/urandom-seed/files/sbin/urandom_seed| 20 + package/system/urngd/Makefile | 48 ++ package/system/urngd/files/urngd.init | 21 ++ target/linux/ath79/Makefile| 3 +- 13 files changed, 184 insertions(+), 62 deletions(-) delete mode 100755 package/base-files/files/etc/init.d/urandom_seed delete mode 100644 package/base-files/files/lib/preinit/81_urandom_seed delete mode 100755 package/base-files/files/sbin/urandom_seed create mode 100644 package/system/urandom-seed/Makefile create mode 100755 package/system/urandom-seed/files/etc/init.d/urandom_seed create mode 100644 package/system/urandom-seed/files/lib/preinit/81_urandom_seed create mode 100755 package/system/urandom-seed/files/sbin/urandom_seed create mode 100644 package/system/urngd/Makefile create mode 100755 package/system/urngd/files/urngd.init -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
