I am using SSL_read and BIO_read on BIO_mem.
I am seeing some behaviour that is confusing and maybe someone can help me
understand.
When I get data off the communication line I do a BIO_write of the data. I
then do a SSL_read( result is a SSL_ERROR_WANT_READ).
So I go and do a BIO_read. What I h
On Mon, Jul 25, 2011, Paul Suhler wrote:
> Hi, all.
>
>
>
> This question is perhaps best answered by Steve Henson, but I'll address
> it to this list.
>
>
>
> I've found that using openssl-SNAP-20110526, we send a Client Hello with
> a signature_algorithms extension that apparently contai
Hi, all.
This question is perhaps best answered by Steve Henson, but I'll address
it to this list.
I've found that using openssl-SNAP-20110526, we send a Client Hello with
a signature_algorithms extension that apparently contains duplicate
entries.
If I understand RFC 5246 correctly, th
Thanks my question was already answered my original certificate was not
rfc compliant and so openssl fails to verify it,
thanks anyway
Nicola
Il 25/07/2011 17:22, lists ha scritto:
On 07/19/2011 08:20 AM, Mailing List SVR wrote:
Hi,
I need to verify the attached certificate (cert.bin) and re
On 07/19/2011 08:20 AM, Mailing List SVR wrote:
Hi,
I need to verify the attached certificate (cert.bin) and read the asn1
info stored in it. I'm using the following commands:
openssl smime -verify -in cert.pem -inform pem -CAfile "signer.pem" >
cert.data
and then:
openssl asn1parse -info
Hello,
DH_generate_key and DH_compute_key seems to take lot of CPU for key and
secret generation respectively.
I think this is the most CPU intensive task in all of the IKEV2 exchanges.
Is there some way to optimize the same, particularly secret computation.
Regards,
Prashant
