svn commit: r239569 - head/etc/rc.d

[Samuel Ports]

Omg cant an freebsd-entropy be created as mailing list already

Sent from my iPhone

On Sep 14, 2012, at 8:09 PM, RW <rwmaillists at googlemail.com> wrote:

> On Fri, 14 Sep 2012 17:25:59 +0100
> Ben Laurie wrote:
>
>> On Fri, Sep 14, 2012 at 3:46 PM, RW <rwmaillists at googlemail.com>
>> wrote:
>>> On Fri, 14 Sep 2012 14:43:53 +0100
>>> Ben Laurie wrote:
>>>
>>>> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb <bz at freebsd.org>
>>>> wrote:
>>>>> 7) send all data to the kernel and hash (arch dependent?) it +
>>>>> counter value into the buffer on overflow, as in b[n] = H(b[n] +
>>>>> c
>>>>> + i[n]) in the kernel
>>>>>   (can control when buffer full and only then take action when
>>>>>   needed, indepedent on how seed data is chosen, uses standard
>>>>>   technology)
>>>>
>>>> IMO, this is the only good option.
>>>
>>> No it isn't. I means that the hashing is unconditional, so anyone
>>> that needs a faster boot needs to patch the kernel.
>>
>> Has anyone measured the cost of doing this? Also, if you really want
>> to turn it off, we could provide a flag.
>
> Yes, read the thread.
>
>>> It has no advantage
>>> whatsoever over a minor change to initrandom.
>>
>> It absolutely has. It applies to all inputs to /dev/random, not just
>> those that come from initrandom.
>
> If the rc script are written correctly it shouldn't matter, there no
> need to write to /dev/random after the boot - it wont do anything
> useful.
>
> It has no advantage over hashing the low-grade entropy in userland
> which is is just couple of lines difference in a shell script.
>
>> Also, should something get to write
>> to it before initrandom, initrandom's input would still be used.
>
> There's no reason to do that, so why do you think it matter?
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"