> From: owner-openssl-us...@openssl.org On Behalf Of Michael Kurecka
> Sent: Thursday, 06 August, 2009 11:30
> Thanks for the help. I was able to determine the list of
> ciphers allowed (SSL_CTX_get_cipher_list), the one of those used
> (SSL_get_current_cipher) and to set specific ciphers
> (SSL
> From: owner-openssl-us...@openssl.org On Behalf Of Alexander Lamaison
> Sent: Thursday, 06 August, 2009 09:12
> I'm trying to avoid passing any C-runtime objects (such as a
> FILE*) across the OpenSSL DLL boundary. This is unsafe as
> the two DLLs may be using different runtime instances whic
Kyle Hamilton:
> OpenSSL is not a true emulation of the socket layer of the OS. It has
> to do more work (public-key cryptography is more work than almost
> anything else outside of physics models), and there is a combination
> of several operations it has to do in the handshake, beyond the
> in
You're missing something. Non-blocking socket I/O is a facility
provided by the OS. OpenSSL can make use of this by taking any
EWOULDBLOCK and convert it to SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. This doesn't help much, it just means that the
program using OpenSSL won't block on a read() o
Thanks for the response. That was my understanding, but I did not want
to assume.
Carter
Carter Browne
CBCS
cbro...@cbcs-usa.com
781-721-2890
Michael S. Zick wrote:
> On Thu August 6 2009, Carter Browne wrote:
>
>> I saw a reference to steps to breaking AES-256 encryption, but that if
>>
On Thu August 6 2009, Carter Browne wrote:
> I saw a reference to steps to breaking AES-256 encryption, but that if
> the implementation were NIST Certified, there should be no concerns.
> However if the implementation were not certified, there could be a
> problem. In reviewing the NIST Certifi
>
> Setting up an SSL connection requires some computationally intensive
> operations using public key algorithms and some others involving the setup of
> digests and ciphers.
>
Thanks Steve for your response.
I realize that. But isn't the objective of using non-blocking
soket/bio is so that the
Thanks for the help. I was able to determine the list of ciphers
allowed (SSL_CTX_get_cipher_list), the one of those used
(SSL_get_current_cipher) and to set specific ciphers
(SSL_CTX_set_cipher_list). I was only able to get information for the
client. The server doesn't seem to use the SSL_CTX obj
I'm trying to avoid passing any C-runtime objects (such as a FILE*)
across the OpenSSL DLL boundary. This is unsafe as the two DLLs may
be using different runtime instances which causes crashes on Windows.
Apparently using BIO_new_file is a safe way to pass a file to a
function as the FILE* is cre
I saw a reference to steps to breaking AES-256 encryption, but that if
the implementation were NIST Certified, there should be no concerns.
However if the implementation were not certified, there could be a
problem. In reviewing the NIST Certification list, the only OpenSSL
versions that were ce
On Wed, Aug 05, 2009, Rij wrote:
> Hi All,
>
> I am opening a SSL connection from a client. The underlying socket and
> BIO are non-blocking. I am observing that SSL_connect is executing
> three times before it completes. While the first and the last call
> return almost immediately (less than 1
Forwarding to openssl-users for public discussion.
In any case you should use a debugger (gdb or appropriate in your
case) to analyse the crash. strace is not of much help here.
Best regards,
Lutz
- Forwarded message from robert.vandon...@gpcbv.com -
From: robert.vandon...@gpcbv.
12 matches
Mail list logo