[LEDE-DEV] [PATCH] base-files: seed /dev/urandom

[Etienne Champetier]

2016-06-14 21:15 GMT+03:00 David Lang <david at lang.hm>:
> On Tue, 14 Jun 2016, Etienne Champetier wrote:
>
>> Hi David,
>>
>> 2016-06-14 20:21 GMT+03:00 David Lang <david at lang.hm>:
>>>
>>> On Tue, 14 Jun 2016, Etienne Champetier wrote:
>>>
>>>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>
>>>>>
>>>>> On 2016-06-13 22:10, Etienne Champetier wrote:
>>>>>>
>>>>>>
>>>>>> Hi John, Felix,
>>>>>>
>>>>>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Felix,
>>>>>>>>
>>>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at 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