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()/
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
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
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
> 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
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!
>
>