So you had a bug in your code. So what?
No bug - read this:
http://www.unix.org/version2/whatsnew/threadspaper.ps :
Registration of fork handlers (pthread_atfork( )). The fork handlers are
routines that are to
be executed in association with calls to the fork( ) function. There are
three
Memory allocated in SSL_set_tlsext_host_name() isn't freed in
SSL_free(). As a workaround one can do
SSL_set_tlsext_host_name(ssl, NULL) before SSL_free(), but I don't
imagine this was what was meant to be implemented. The bug is easy
to replicate using the code below, using valgrind or
Hello!
During the OpenSSL source investigation I found some strange call in
function BN_mod_inverse:
...
if (sign 0)
{
if (!BN_sub(Y,n,Y)) goto err;
}
...
But! Declaration of BN_sub looks like this:
int BN_sub(BIGNUM *r, const BIGNUM *a, const BIGNUM *b)
In some circumstances r
Sorry, I don't think that breaks any const rules.
See explanation and example in ISO/IEC 14882 section 7.1.5.1.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, January 30, 2008 3:59 PM
To: openssl-dev@openssl.org
Hi, Yair Elharrar!
Sorry, I don't think that breaks any const rules.
See explanation and example in ISO/IEC 14882 section 7.1.5.1.
First of all, OpenSSL was written in C, so ISO/IEC 14882 is not a
subject to reffer to (it is the C++ standard).
Let's see in ISO/IEC 9899 section 6.7.3:
The
Hi Eugene,
ISO/IEC 9899 doesn't discuss this directly, but says in section 6.7.5.1:
...const int *ptr_to_constant;
int *const constant_ptr;
The contents of any object pointed to by ptr_to_constant shall not be modified
through that pointer...
in BN_sub, b is a const BIGNUM *, hence
Hi, Yair Elharrar!
For me it looks bad. :-/ Because, BN_sub doesn't handle this situation (r = b):
1) BN_sub call BN_uadd(r,a,b), but r = b, then
2) BN_sub change r-neg, but r = b, then
3) BN_sub call BN_expand(r), then
4) BN_sub call BN_ucmp(a,b), but b here is not that b that was at the
Hi,
I have a BMC5825 card from Silicom that is supposed to do over
10'000 rsa per second.
In practice Proto Balance can do about 1900 fresh SSL connections
per second, on an Intel Core2 Duo 2.2Ghz. But I think more work
can vastly improve this.
(Without the card I get about 700 per second -
On Wed, Jan 30, 2008 at 09:32:34PM +0200, Paul Sheer wrote:
Hi,
I have a BMC5825 card from Silicom that is supposed to do over
10'000 rsa per second.
Never going to happen. The context switches to talk to the
accellerator are too expensive, and OpenSSL doesn't support (nor
have any way to
no I meant that I am already getting 2000/sec on the *server*.
By my calculations I should be able to get 3000/sec on the server
with the optimizations I want to do.
2000/sec is a good place to be, on a client. Expect less on a
server, unfortunately.
I replaced OPENSSL_cleanse() {...}
OPENSSL_cleanse() doesn't zero memory regions, it fills them with
pseudo-random data.
Edit crypto/mem_clr.c and replace that code with memset(ptr,'\0',len); and
just clear the region - you'll see a significant performance boost if
that's your majorbottleneck.
Just be aware that some hypothetical
On Thu, Jan 31, 2008, Peter Waltenberg wrote:
OPENSSL_cleanse() doesn't zero memory regions, it fills them with
pseudo-random data.
Edit crypto/mem_clr.c and replace that code with memset(ptr,'\0',len); and
just clear the region - you'll see a significant performance boost if
that's your
12 matches
Mail list logo
