RE: PEM_read_bio_RSA_PUBKEY
Hi Dave
thanks a lot for the explanation. That makes a lot clearer to me. I added
some code to read out possible errors and there is none on the write
method. However there is a strange one on read:
error code pubkey: 537297017 in bio_lib.c line 297.
error data:
error string: error:20068079:BIO routines:BIO_gets:unsupported method
error code pubkey: 151441516 in pem_lib.c line 696.
error data:
error string: error:0906D06C:PEM routines:PEM_read_bio:no start line
For me that sounds as if it does not fine the - BEGIN PUBKEY
line. So I checked with wireshark and it is there. The PEM string is
distributed over 3 packets but it is continuous data (there is no other
data in those packets). So where does this error come from? Any ideas? I
cannot do anything about the method here, right?
BTW I checked that this error is really triggered by the read function and
not by any BIO function before that function.
best regards
Carolin
From: owner-openssl-us...@openssl.org On Behalf Of Carolin Latze Sent:
Monday, 03 September, 2012 13:39
I try to send an RSA public from one entity to another using socket
BIOs. I use PEM_write_bio_RSA_PUBKEY and PEM_read_bio_RSA_PUBKEY to do
that. I also tried with PEM_{write|read}_bio_RSAPublicKey. Both have
the
same behaviour in my case. The write function seems to work just fine.
I
am able to see the public key on the wire (using wireshark). However,
the read function just crashes. It looks as if it reads an endless
amount of data and I have no idea why. Are those function
actually meant
to send data over a socket bio?
The PEM routines are meant to send or store over practically any
channel. The DER routines are meant to send/store over any 8-bit clean
channel, which many socket protocols also do. (TCP/IP itself and a plain
socket does, but some protocols built on top of TCP/IP like SMTP and
HTTP don't, while some like FTP do.)
Either pair should work, but mixing them should not. The RSAPublicKey
routines use the raw PKCS#1 format, and the RSA_PUBKEY routines use
the generic X.509 PublicKeyInfo format which *contains* the PKCS#1.
Although semantically equivalent, these are not the same thing.
But if you get this (or pretty much anything else) wrong, the read
routine shouldn't crash. It should return null with error information
stored in the error queue; this is not the same as either crashing or
reading endlessly. In fact reading endlessly wouldn't crash either by my
definition so I can't guess what you mean actually happens.
This is how I call them:
on party A:
RSA rsa;
init rsa, generate keys
PEM_write_bio_RSA_PUBKEY(sockbio,rsa);
on party B:
rsa = RSA_new();
PEM_read_bio_RSAPublicKey(sockbio,rsa,0,0);
Something wrong with the way I call the functions?
If you are mismatching RSA_PUBKEY to RSAPublicKey see above.
Even if not, you definitely should check for error on the read
routine and at least display something. The write routine is
much less likely to fail, but even so as general good practice
you should check it too.
Nit: personally in C I would write NULL rather than 0
for a null pointer -- just so it's visible to humans,
although it makes no difference to the compiler.
Unfortunately C++ doesn't support this until recently.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: PEM_read_bio_RSA_PUBKEY
Hi,
I went on reading about this error and figured out that the socket bio
does not support the BIO_gets method. Is it possible that
PEM_read_bio_RSA_PUBKEY uses BIO_gets internally and is therefore not
really compatible with a socket bio?
In order to verify that I created a buffer BIO (BIO_f_buffer()) on top of
the socket bio for the read function. And this just works. Is this the
desired way to do this? I can live with it, but since it was not
documented (or maybe I just missed it), I did not expect it.
best regards and thanks a lot again for the help
Carolin
Hi Dave
thanks a lot for the explanation. That makes a lot clearer to me. I
added
some code to read out possible errors and there is none on the write
method. However there is a strange one on read:
error code pubkey: 537297017 in bio_lib.c line 297.
error data:
error string: error:20068079:BIO routines:BIO_gets:unsupported method
error code pubkey: 151441516 in pem_lib.c line 696.
error data:
error string: error:0906D06C:PEM routines:PEM_read_bio:no start line
For me that sounds as if it does not fine the - BEGIN PUBKEY
line. So I checked with wireshark and it is there. The PEM string is
distributed over 3 packets but it is continuous data (there is no other
data in those packets). So where does this error come from? Any ideas? I
cannot do anything about the method here, right?
BTW I checked that this error is really triggered by the read function
and
not by any BIO function before that function.
best regards
Carolin
From: owner-openssl-us...@openssl.org On Behalf Of Carolin Latze Sent:
Monday, 03 September, 2012 13:39
I try to send an RSA public from one entity to another using socket
BIOs. I use PEM_write_bio_RSA_PUBKEY and PEM_read_bio_RSA_PUBKEY to do
that. I also tried with PEM_{write|read}_bio_RSAPublicKey. Both have the
same behaviour in my case. The write function seems to work just fine.
I
am able to see the public key on the wire (using wireshark). However,
the read function just crashes. It looks as if it reads an endless
amount of data and I have no idea why. Are those function
actually meant
to send data over a socket bio?
The PEM routines are meant to send or store over practically any
channel. The DER routines are meant to send/store over any 8-bit clean
channel, which many socket protocols also do. (TCP/IP itself and a plain
socket does, but some protocols built on top of TCP/IP like SMTP and
HTTP don't, while some like FTP do.)
Either pair should work, but mixing them should not. The RSAPublicKey
routines use the raw PKCS#1 format, and the RSA_PUBKEY routines use
the generic X.509 PublicKeyInfo format which *contains* the PKCS#1.
Although semantically equivalent, these are not the same thing.
But if you get this (or pretty much anything else) wrong, the read
routine shouldn't crash. It should return null with error information
stored in the error queue; this is not the same as either crashing or
reading endlessly. In fact reading endlessly wouldn't crash either by my
definition so I can't guess what you mean actually happens.
This is how I call them:
on party A:
RSA rsa;
init rsa, generate keys
PEM_write_bio_RSA_PUBKEY(sockbio,rsa);
on party B:
rsa = RSA_new();
PEM_read_bio_RSAPublicKey(sockbio,rsa,0,0);
Something wrong with the way I call the functions?
If you are mismatching RSA_PUBKEY to RSAPublicKey see above.
Even if not, you definitely should check for error on the read
routine and at least display something. The write routine is
much less likely to fail, but even so as general good practice
you should check it too.
Nit: personally in C I would write NULL rather than 0
for a null pointer -- just so it's visible to humans,
although it makes no difference to the compiler.
Unfortunately C++ doesn't support this until recently.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: PEM_read_bio_RSA_PUBKEY
Is it possible that PEM_read_bio_RSA_PUBKEY uses BIO_gets internally
Sometimes the best answer to that sort of question -- sadly, perhaps, but
true nonetheless -- is to look at the source code. Not so hard to read as I
had at first supposed.
Charles
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Carolin Latze
Sent: Tuesday, September 04, 2012 5:03 AM
To: openssl-users@openssl.org
Subject: RE: PEM_read_bio_RSA_PUBKEY
Hi,
I went on reading about this error and figured out that the socket bio
does not support the BIO_gets method. Is it possible that
PEM_read_bio_RSA_PUBKEY uses BIO_gets internally and is therefore not
really compatible with a socket bio?
In order to verify that I created a buffer BIO (BIO_f_buffer()) on top of
the socket bio for the read function. And this just works. Is this the
desired way to do this? I can live with it, but since it was not
documented (or maybe I just missed it), I did not expect it.
best regards and thanks a lot again for the help
Carolin
Hi Dave
thanks a lot for the explanation. That makes a lot clearer to me. I
added
some code to read out possible errors and there is none on the write
method. However there is a strange one on read:
error code pubkey: 537297017 in bio_lib.c line 297.
error data:
error string: error:20068079:BIO routines:BIO_gets:unsupported method
error code pubkey: 151441516 in pem_lib.c line 696.
error data:
error string: error:0906D06C:PEM routines:PEM_read_bio:no start line
For me that sounds as if it does not fine the - BEGIN PUBKEY
line. So I checked with wireshark and it is there. The PEM string is
distributed over 3 packets but it is continuous data (there is no other
data in those packets). So where does this error come from? Any ideas? I
cannot do anything about the method here, right?
BTW I checked that this error is really triggered by the read function
and
not by any BIO function before that function.
best regards
Carolin
From: owner-openssl-us...@openssl.org On Behalf Of Carolin Latze Sent:
Monday, 03 September, 2012 13:39
I try to send an RSA public from one entity to another using socket
BIOs. I use PEM_write_bio_RSA_PUBKEY and PEM_read_bio_RSA_PUBKEY to do
that. I also tried with PEM_{write|read}_bio_RSAPublicKey. Both have the
same behaviour in my case. The write function seems to work just fine.
I
am able to see the public key on the wire (using wireshark). However,
the read function just crashes. It looks as if it reads an endless
amount of data and I have no idea why. Are those function
actually meant
to send data over a socket bio?
The PEM routines are meant to send or store over practically any
channel. The DER routines are meant to send/store over any 8-bit clean
channel, which many socket protocols also do. (TCP/IP itself and a plain
socket does, but some protocols built on top of TCP/IP like SMTP and
HTTP don't, while some like FTP do.)
Either pair should work, but mixing them should not. The RSAPublicKey
routines use the raw PKCS#1 format, and the RSA_PUBKEY routines use
the generic X.509 PublicKeyInfo format which *contains* the PKCS#1.
Although semantically equivalent, these are not the same thing.
But if you get this (or pretty much anything else) wrong, the read
routine shouldn't crash. It should return null with error information
stored in the error queue; this is not the same as either crashing or
reading endlessly. In fact reading endlessly wouldn't crash either by my
definition so I can't guess what you mean actually happens.
This is how I call them:
on party A:
RSA rsa;
init rsa, generate keys
PEM_write_bio_RSA_PUBKEY(sockbio,rsa);
on party B:
rsa = RSA_new();
PEM_read_bio_RSAPublicKey(sockbio,rsa,0,0);
Something wrong with the way I call the functions?
If you are mismatching RSA_PUBKEY to RSAPublicKey see above.
Even if not, you definitely should check for error on the read
routine and at least display something. The write routine is
much less likely to fail, but even so as general good practice
you should check it too.
Nit: personally in C I would write NULL rather than 0
for a null pointer -- just so it's visible to humans,
although it makes no difference to the compiler.
Unfortunately C++ doesn't support this until recently.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL
HTTPS connection hangs during SSL handshake
I am using OpenSSL version : openssl-1.0.0j in our production. I am facing a strange problem where the SSL connection simply hangs during initial handshake when requested from our office IP address. When I run the same command from another IP address it works fine. From office IP (Unsuccessful connection): [root@gateway ]# openssl s_client -connect test.mydomain.com:443 CONNECTED(0003) From a different IP (Successful connection): ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect test.mydomain.com:443 CONNECTED(0003) depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com --- Server certificate -BEGIN CERTIFICATE- REMOVED FOR SECURITY REASON -END CERTIFICATE- subject=/O=*.mydomain.com/OU=Domain Control Validated/CN=*.mydomain.com issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 --- No client certificate CA names sent --- SSL handshake has read 4827 bytes and written 435 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: RC4-SHA Session-ID: 276ADBFB75336E7E870C5E109B4C5F6AFB8328C8775029EF135C5DA6F8608533 Session-ID-ctx: Master-Key: 22B470A67XXXB50ED6237BE9 Key-Arg : None Start Time: 1346765613 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain Any ideas ? -- Warm Regards Supratik __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PEM_read_bio_RSA_PUBKEY
I did that already and saw already that BIO_gets is called. I just left
the question open since I don't understand the reason behind this. It
forces me to use a buffer BIO that I only need for that one read. But I
agree that this is a workaround that is doable
Is it possible that PEM_read_bio_RSA_PUBKEY uses BIO_gets internally
Sometimes the best answer to that sort of question -- sadly, perhaps, but
true nonetheless -- is to look at the source code. Not so hard to read as
I
had at first supposed.
Charles
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Carolin Latze
Sent: Tuesday, September 04, 2012 5:03 AM
To: openssl-users@openssl.org
Subject: RE: PEM_read_bio_RSA_PUBKEY
Hi,
I went on reading about this error and figured out that the socket bio
does not support the BIO_gets method. Is it possible that
PEM_read_bio_RSA_PUBKEY uses BIO_gets internally and is therefore not
really compatible with a socket bio?
In order to verify that I created a buffer BIO (BIO_f_buffer()) on top of
the socket bio for the read function. And this just works. Is this the
desired way to do this? I can live with it, but since it was not
documented (or maybe I just missed it), I did not expect it.
best regards and thanks a lot again for the help
Carolin
Hi Dave
thanks a lot for the explanation. That makes a lot clearer to me. I
added
some code to read out possible errors and there is none on the write
method. However there is a strange one on read:
error code pubkey: 537297017 in bio_lib.c line 297.
error data:
error string: error:20068079:BIO routines:BIO_gets:unsupported method
error code pubkey: 151441516 in pem_lib.c line 696.
error data:
error string: error:0906D06C:PEM routines:PEM_read_bio:no start line
For me that sounds as if it does not fine the - BEGIN PUBKEY
line. So I checked with wireshark and it is there. The PEM string is
distributed over 3 packets but it is continuous data (there is no other
data in those packets). So where does this error come from? Any ideas? I
cannot do anything about the method here, right?
BTW I checked that this error is really triggered by the read function
and
not by any BIO function before that function.
best regards
Carolin
From: owner-openssl-us...@openssl.org On Behalf Of Carolin Latze Sent:
Monday, 03 September, 2012 13:39
I try to send an RSA public from one entity to another using socket
BIOs. I use PEM_write_bio_RSA_PUBKEY and PEM_read_bio_RSA_PUBKEY to do
that. I also tried with PEM_{write|read}_bio_RSAPublicKey. Both have the
same behaviour in my case. The write function seems to work just fine.
I
am able to see the public key on the wire (using wireshark). However,
the read function just crashes. It looks as if it reads an endless
amount of data and I have no idea why. Are those function
actually meant
to send data over a socket bio?
The PEM routines are meant to send or store over practically any
channel. The DER routines are meant to send/store over any 8-bit clean
channel, which many socket protocols also do. (TCP/IP itself and a plain
socket does, but some protocols built on top of TCP/IP like SMTP and
HTTP don't, while some like FTP do.)
Either pair should work, but mixing them should not. The RSAPublicKey
routines use the raw PKCS#1 format, and the RSA_PUBKEY routines use
the generic X.509 PublicKeyInfo format which *contains* the PKCS#1.
Although semantically equivalent, these are not the same thing.
But if you get this (or pretty much anything else) wrong, the read
routine shouldn't crash. It should return null with error information
stored in the error queue; this is not the same as either crashing or
reading endlessly. In fact reading endlessly wouldn't crash either by my
definition so I can't guess what you mean actually happens.
This is how I call them:
on party A:
RSA rsa;
init rsa, generate keys
PEM_write_bio_RSA_PUBKEY(sockbio,rsa);
on party B:
rsa = RSA_new();
PEM_read_bio_RSAPublicKey(sockbio,rsa,0,0);
Something wrong with the way I call the functions?
If you are mismatching RSA_PUBKEY to RSAPublicKey see above.
Even if not, you definitely should check for error on the read
routine and at least display something. The write routine is
much less likely to fail, but even so as general good practice
you should check it too.
Nit: personally in C I would write NULL rather than 0
for a null pointer -- just so it's visible to humans,
although it makes no difference to the compiler.
Unfortunately C++ doesn't support this until recently.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Measuring SHA1 performance in CPU cycles [SOLVED]
Amit amit.uttam@... writes: Hello, Looking at *crypto/sha/asm/sha1-x86_64.pl*, there is a measurement that states 5.3 cycles / byte when computing the sha1. How was this measurement obtained? I tried using linux perf tools and got close to this figure but I am not sure if I am performing the correct test. Thanks, Amit Linux perf tools is great, however, if you just want to measure the number of cycles for *SHA1_Update*, systemtap is a better option. Note that in order to support user space probes, you need to compile the latest kernel (3.5 or greater) and use the latest systemtap from git. Running systemtap on a Core i7 2600 3.4GHz, I was able to get around 5 cycles/byte +-0.2 cycles. Which is consistent with the measurement in sha1-x86_64.pl. Thanks, Amit __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
asn1 parsing tutorial
Is there any tutorial or other documentation on how to use the openssl asn1 parsing C functions? That is, not the command line. The man pages are empty. I found that the asn1parse command line utility works, but the asn1pars.c code is completely uncommented. It will be a chore to reverse engineer it with a debugger. ~~ Use case: I have to parse a non-standard X.509 certificate that openssl cannot handle at a higher level. I think I have to parse at a low level and pull out the data I need. Any better ideas? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
C API to determine OpenSSL version?
Is there a C-callable function that an application may call to determine the version of the OpenSSL library with which it is linked? Thanks, Charles __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: C API to determine OpenSSL version?
Is there a C-callable function that an application may call to determine the version of the OpenSSL library with which it is linked? See the SSLeay() and SSLeay_version() functions, depending on whether you wish to retrieve a long containing the version, or a textual string. Hope this helps, TJ ~ No day in which something is learned is ever wasted. -TJ Saunders ~ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: C API to determine OpenSSL version?
Never mind. Found it: http://www.openssl.org/docs/crypto/SSLeay_version.html Hard to search for. Google SSL version and you get a lot of irrelevant hits. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Charles Mills Sent: Tuesday, September 04, 2012 2:23 PM To: openssl-users@openssl.org Subject: C API to determine OpenSSL version? Is there a C-callable function that an application may call to determine the version of the OpenSSL library with which it is linked? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: asn1 parsing tutorial
On Tue, Sep 04, 2012, Ken Goldman wrote: Use case: I have to parse a non-standard X.509 certificate that openssl cannot handle at a higher level. I think I have to parse at a low level and pull out the data I need. Is this the OAEP certificate issue? It should be possible to retrieve the public key information by adding an ASN1 alias for the relevant OID, but it wont retrieve OAEP parameters without additional coding. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PEM_read_bio_RSA_PUBKEY
From: owner-openssl-us...@openssl.org On Behalf Of Carolin Latze Sent: Tuesday, 04 September, 2012 08:03 I went on reading about this error and figured out that the socket bio does not support the BIO_gets method. Is it possible that PEM_read_bio_RSA_PUBKEY uses BIO_gets internally and is therefore not really compatible with a socket bio? I'd expect PEM_read* uses BIO_gets, since PEM format is line-oriented. And the error report you got indicated it did. In order to verify that I created a buffer BIO (BIO_f_buffer()) on top of the socket bio for the read function. And this just works. Is this the desired way to do this? I can live with it, but since it was not documented (or maybe I just missed it), I did not expect it. Guess so. One major goal of the BIO architecture is to allow plugging together components like that, so it seems quite reasonable. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
