Re: Self-initialization of locking/threadid callbacks and auto-detection of features

2013-10-22 Thread Nico Williams
On Wed, Oct 23, 2013 at 08:32:35AM +1000, Peter Waltenberg wrote: > There is no 'safe' way to do this other than hardwired. Admitted, we have a > fairly ugly stack on which to find that out, multiple independently > developed lumps of code jammed into the same process, quite a few using > dlopen()/

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

2013-10-22 Thread Peter Waltenberg
 The simplest fix involves setting the default only once, as wih the callbacks, but here I feel that's a shaky idea, that I should allow RAND method changes at any time, in a thread-safe manner -- more work for me, but less surprising. There is no 'safe' way to do this other than hardwired. Admi

[openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

2013-10-22 Thread Gueron, Shay via RT
Hello all, This patch is a contribution to OpenSSL. It offers an efficient and constant-time implementation of EC multiplication for NIST P256 curve. It accelerated ECDSA (sign and verify) as well as ECDH (compute and generate key), for the P256 curve. The implementation is based on Montgomery

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

2013-10-22 Thread Nico Williams
On Oct 22, 2013 10:28 AM, "Ben Laurie" wrote: > On 22 October 2013 06:47, Nico Williams wrote: >> What I need to know: >> >> - should i add new targets to ./Configure? for now I modified the linux-elf target, but this feels wrong to me. >> >> - what about Windows? I either need to have differ

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

2013-10-22 Thread Nico Williams
> But I could have a target that has a weak dependency on pthreads and is safe when the library is present. Ditto Windows (be unsafe pre-vista/2008, safe in vista/2008 and later, using same OpenSSL DLLs builds). I'd rather add this variation later, after the meat of this work is done, assuming su

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

2013-10-22 Thread Ben Laurie
On 22 October 2013 06:47, Nico Williams wrote: > On Monday, October 21, 2013, Salz, Rich wrote: > >> I like your proposal, but I'd prefer to see an "already initialized" >> error code returned. Or a flag to the (new?) init api that says "ignore if >> already set" >> > > Thanks for your reply! > >