2016-06-14 21:15 GMT+03:00 David Lang <da...@lang.hm>: > On Tue, 14 Jun 2016, Etienne Champetier wrote: > >> Hi David, >> >> 2016-06-14 20:21 GMT+03:00 David Lang <da...@lang.hm>: >>> >>> On Tue, 14 Jun 2016, Etienne Champetier wrote: >>> >>>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <n...@nbd.name>: >>>>> >>>>> >>>>> On 2016-06-13 22:10, Etienne Champetier wrote: >>>>>> >>>>>> >>>>>> Hi John, Felix, >>>>>> >>>>>> 2016-06-13 13:55 GMT+02:00 John Crispin <j...@phrozen.org>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 13/06/2016 00:56, Etienne Champetier wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Felix, >>>>>>>> >>>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <n...@nbd.name>: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option >>>>>>> and >>>>>>> lock this and the dnssec time stuff with it and default it to 0 >>>>>> >>>>>> >>>>>> >>>>>> Security can't be opt in ! >>>>>> When you see "random: ubus urandom read with 4 bits of entropy >>>>>> available" let's hope it's not security sensitive, because 2^4 will >>>>>> not take a lot of time to bruteforce... >>>>> >>>>> >>>>> First of all, the kernel entropy estimation is *really* pessimistic, so >>>>> there will be a lot more random bits at this point than just 4. >>>>> >>>>>> Before we try to minimize writes, how much writes are we talking >>>>>> about? >>>>>> my openwrt routers have multiple months of uptime, and even if we get >>>>>> down to 1 week, that gets us to 53 writes a year. >>>>>> How much writes can a flash handle these days? >>>>> >>>>> >>>>> I'm more concerned about the worst case than the average case here. >>>>> There are people that do a forced reboot every day (as a stability >>>>> workaround), or only power up their devices during specific times of >>>>> the >>>>> day (multiple reboots per day). This can easily add up to bigger >>>>> numbers. >>>>> >>>>> Also, adding something like this makes other people want to add even >>>>> more stuff that writes to flash on every boot, as you've so clearly >>>>> demonstrated by pointing out that this behavior are already done for >>>>> dnssec/dnsmasq. >>>> >>>> >>>> >>>> Ok, let's find a middle ground :) >>>> What about saving a seed if there is none (on boot), and then using an >>>> ntp hotplug (stratum event) and save a new seed if older than say 1 >>>> week? >>> >>> >>> >>> The worst thing that you can do is to use the same seed on multiple >>> boots. >> >> >> I agree that we should use a new seed each time, >> but are you suggesting that using the same seed is worse than no seed? > > > I would argue that from a technical point of view that the difference > between using no seed and using the same seed for a week or so at a time is > so small as to be almost meaningless in practice. > > From a Social point of view, adding such a thing in is a net negative > because it gives a false sense of security and encourages others to fall > into the same trap. > > Doing this at first boot (once sufficiant randomness is available) so that > not every device out there with the same build starts out with an identical > pool, but beyond that, either do it every boot or don't bother.
I agree that giving false sense of security should be avoided. > >> Do you have some links to back your claim? > > > google for "security theater" and you will find lots of discussion about the > problems of things that people do to feel safer that end up being net > negative. > >> Seeding here is just writing 512 bytes from getrandom() back into >> /dev/urandom, so this gets mixed with what's already available without >> affecting entropy estimation > > > and even if this is written out hourly (by a system frequently rebooting), > hitting a very conservative 100,000 writes would take 11 years. Also agree... Felix, John, is your nack on writing on every boot final? > > If you haven't been following it, it's worth going back and reading the > discussion on urandom that has been taking place on the kernel mailing list > over the last couple of months. There is a re-work of urandom planned to go > into the next release, specifically targeting OpenWRT/LEDE type devices. I just read the link you provided (thanks), not the previous discussions (i will try to read it) Etienne > > David Lang _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
