On Feb 24, 2015 3:08 AM, "Leigh" <lei...@gmail.com> wrote:
>
> On 24 February 2015 at 10:55, Pierre Joye <pierre....@gmail.com> wrote:
> > It should use the session.entropy_file setting as it aims to be the
exact
> > same thing. It also allows custom entropy src (better ones for higher
> > demands) as well.
>
> I disagree. We want to take responsibility away from the user to
> choose the best source of entropy. The session.entropy_file setting
> also does not allow arc4random to be used, which is a source of
> cryptographic quality random without using a file descriptor.
>

Sorry, my reply could have been confusing.

I was not trying to say It should use only this setting. However it should
be able to use it. As it is a requirement and is part of the configure
requirements to begin with.

> In fact I had planned for a future RFC where we allow
> session.entropy_file to use using random_bytes(). So the "best" source
> is chosen automatically. (If you think there are better sources not
> covered by this patch, please let me know, I would like it to be
> complete)

I rather prefer to be able to choose. Maybe make it system instead of
INI_ALL if the users ability to choose wisely are questionable.

> There is an aspect of this that has been left for "future work", but
> if the list thinks it is important I can implement it for this RFC.
> The issue is that on Linux it still does not provide a way of getting
> random bytes without using a file descriptor. This is important for a
> couple of reasons, 1) It means chroot environments don't require
> /dev/*random 2) it prevents fd-exhaustion attacks that force lower
> quality randomness. LibreSSL-portable has a very good implementation
> of this using the Linux getrandom syscall (Kernel >= 3.17) that I can
> phpise and include if we think it is necessary.

It is all the same setting. What is done on windows can be applied on any
other platforms. Either use a path or a method, it just works fine.

There are many different RNG providers, daemons or other services. I have
seen customers using some of them (together) to generate enough data for
their needs (need a lot of entropy data). By enough data I mean to be 200%
sure that the entropy is good enough at any time no matter how much data is
being fetched.

I am also unsure about random_get_int, why only integer? It is also
important that doing so the results is per se not crypto safe anymore. But
still handy for codes required random integers (or other types). If it is
kept, I would also prefer to name it random_get_<type> instead, for clarity.

Cheers,

Pierre

Reply via email to