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

[David Lang]

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.

> 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.

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.

David Lang