On Fri, Aug 23, 2013 at 1:12 AM, Patrick Pelletier
wrote:
> On 8/22/13 12:46 PM, Nico Williams wrote:
>> The parent might be multi-threaded, leading to the risk that a thread
>> in the parent and the child will obtain the same PRNG outputs until
>> the parent thread that fork()ed completes the re-
On 8/22/13 12:46 PM, Nico Williams wrote:
The parent might be multi-threaded, leading to the risk that a thread
in the parent and the child will obtain the same PRNG outputs until
the parent thread that fork()ed completes the re-seeding.
That's a good point; I hadn't thought of that.
Also, i
> > (So we probably should use the current time in addition to the PID to
> get a
> > general solution to the PID wrap-around problem even on systems where
> > actual independent reseeding isn't possible.)
>
> The FIPS PRNG uses a combination of PID, a counter and a form of system
> timer
> for the
On Thu, Aug 22, 2013 at 2:46 PM, Nico Williams wrote:
> Use of fork() presents many problems, not the least of which is a
> performance problem in multi-threaded processes with very large heaps
> and high page dirtying rates, such as Java programs. [...]
Also, obviously, web browsers.
__
On Thu, Aug 22, 2013 at 1:00 AM, Patrick Pelletier
wrote:
> On 8/21/13 8:55 AM, Nico Williams wrote:
>
>> OpenSSL should use pthread_atfork() and mix in more /dev/urandom into
>> its pool in the child-side of the fork(), Only a child-side handler
>> is needed, FYI, unless there's locks to acquire
On Thu, Aug 22, 2013 at 4:50 AM, Bodo Moeller wrote:
>
> Most other libraries I've seen handle this by saving the pid in a static
>> variable, and then comparing the current pid to it. This has the advantage
>> of not needing pthreads, and also of only adding the entropy to the child
>> if it is
> Most other libraries I've seen handle this by saving the pid in a static
> variable, and then comparing the current pid to it. This has the advantage
> of not needing pthreads, and also of only adding the entropy to the child
> if it is actually needed (i. e. it doesn't exec after fork).
>
We m
On 8/21/13 8:55 AM, Nico Williams wrote:
OpenSSL should use pthread_atfork() and mix in more /dev/urandom into
its pool in the child-side of the fork(), Only a child-side handler
is needed, FYI, unless there's locks to acquire and release, in which
case you also need a pre-fork and parent-side
On Wed, Aug 21, 2013 at 5:41 AM, Ben Laurie wrote:
> Something needs to be done, but won't this re-introduce the problem of
> /dev/random starvation, leading to more use of /dev/urandom (on platforms
> where this is a problem)?
>
> Mixing in the time seems like a safer solution that should also fi
On Wed, Aug 21, 2013 at 2:19 AM, Patrick Pelletier
wrote:
> An easy way to work around this, if you don't mind linking against pthreads,
> is to do this at the start of your application, after initializing OpenSSL:
>
> typedef void (*voidfunc) (void);
>
> if (ENGINE_get_default_RAND () == NULL)
>
On 21 August 2013 03:19, Patrick Pelletier wrote:
> On 8/15/13 11:51 PM, Patrick Pelletier wrote:
>
>> On Aug 15, 2013, at 10:38 PM, Nico Williams wrote:
>>
>> Hmm, I've only read the article linked from there:
>>> http://android-developers.**blogspot.com/2013/08/some-**
>>> securerandom-thought
On 8/21/13 12:19 AM, Patrick Pelletier wrote:
Nikolay Elenkov wrote a proof-of-concept that shows the pid-wrapping bug
on Android, and then I took it one step further and wrote a
proof-of-concept using OpenSSL in C, demonstrating that this is an
underlying OpenSSL bug:
https://gist.github.com/p
12 matches
Mail list logo
