Re: Problem with rsa_keygen
I have the engine in a dynamic library and there's not relevant part of the
code. If I overwrite rsa_keygen function and if I do something or nothing
but return 1 I get segmentation fault but it's not my function, my
function ends ok and invokes the return instruction. The example code I
wrote is an example that makes OpenSSL ends with segmentation fault.
I don't know how to get gdb output from a dynamic library or OpenSSL.
2010/9/23 Christian Hohnstaedt christ...@hohnstaedt.de
On Thu, Sep 23, 2010 at 10:08:40AM +0200, Nacho ?lvarez wrote:
That's not the problem, I think, because if the only instruction of the
function is:
int rsa_keygen (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb) {
return 1;
}
I get the segmentation fault when the rsa_keygen ends. But if I return
0
or -1 (errors) OpenSSL reports me error in genrsa and call ends ok (no
segmentation fault or something like that).
What about posting the relevant part of the code?
And the gdb output.
It would help a lot.
Cheers
Christian
2010/9/22 Christian Hohnstaedt christ...@hohnstaedt.de
On Wed, Sep 22, 2010 at 03:41:30PM +0200, Nacho ?lvarez wrote:
Hello everybody
Several months ago I developed an OpenSSL PKCS#11 engine for Windows
XP
and
it worked ok (it was compiled with MinGW).
Now I'm trying to compile it on Linux (Debian 5 with GCC 4.3.1) but I
have
the next problem:
In the overwritten function *rsa_keygen* (whose signature is *int
rsa_keygen
(RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb)*) always when the
function
ends (after the return instrucction) System reports me *Segmentation
Fault*.
You overwrote you return address on the stack most probably by
accessing a locally declared array out of bounds.
Cheers
Christian
__
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: regarding binary size in OpenSSL 1.0.0a
On 23-09-2010 07:53, Madhu Gowda wrote: Hi All, We are using OpenSSL (binaries built as static version) in our application. We are using the version 0.9.8i and the size of libeay32.lib (built in 32 bit windows) is 3.392 MB. We are thinking of updating to latest version of OpenSSL 1.0.0a. When we built the binaries for 1.0.0a (static version on 32 bit windows) from source code we are getting the size of libeay32.lib as 12.374 MB. Is there any reason for such a huge difference in size of libeay32.lib ? Or I am missing something while building the binaries ? Regards, Madhu Gowda F.Y.I. 1. My compile of OpenSSL 1.0.0a is also 12.something MB 2. I don't know if the added size is due to additional featueres (that you don't need to call and link in) or not. Personally, I worry much more about the size of the linked program or DLL than the size of the .lib files. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: regarding binary size in OpenSSL 1.0.0a
Jakob Bohm wrote: On 23-09-2010 07:53, Madhu Gowda wrote: Hi All, We are using OpenSSL (binaries built as static version) in our application. We are using the version 0.9.8i and the size of libeay32.lib (built in 32 bit windows) is 3.392 MB. We are thinking of updating to latest version of OpenSSL 1.0.0a. When we built the binaries for 1.0.0a (static version on 32 bit windows) from source code we are getting the size of libeay32.lib as 12.374 MB. Is there any reason for such a huge difference in size of libeay32.lib ? Or I am missing something while building the binaries ? Regards, Madhu Gowda F.Y.I. 1. My compile of OpenSSL 1.0.0a is also 12.something MB 2. I don't know if the added size is due to additional featueres (that you don't need to call and link in) or not. Personally, I worry much more about the size of the linked program or DLL than the size of the .lib files. For us 1.0.0a static release build 32-bit windows resulted in libeay32.lib being 11,5 MB (12 157 804 bytes). Same for 0.9.8b was 9,13 MB (9 584 330 bytes). Can't tell why your 0.9.8i was so much smaller. Good luck, Per __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem to verify a signed file.
Hello, We are signing files with openssl. We use this command (UNIX machine): openssl smime -sign -binary -outform PEM -in myfile.dat -out myfile.dat.sig -signer cert.pem -inkey keyfile.pem To verify the signed file, we use this other command (PC with Windows): openssl smime -verify -noverify -inform PEM -in myfile.fil.sig -signer cert.pem -content fichero.fil NUL 2myfile.log The file to sing (myfile.dat) is a binary file. This has always worked right, but some days ago, we are getting an error message when we try to verify a signed file. The error is: Verification failure 1072:error:21071065:PKSC7 routines:PKCS7_signatureVerify:digest failure:.\crypto \pkcs7\pk7_doit.c:1051: 1072:error:21075069:PKSC7 routines:PKCS7_verify:signature failure:.\crypto\pkcs7 \pk7_smime.c:410: We are using openssl 1.0.0. Please, could somebody help me to find what is the problem? José
Re: Problem with rsa_keygen
I think I know what's the problem. If you return 1 in rsa_keygen, OpenSSL
expects a correct RSA key. I find out muy PKCKS#11 device don't work ok and
the keys was wrong so OpenSSL didn't recive a correct RSA key and when I
returned 1 withouh generate an RSA key was the same problem, OpenSSL hadn't
a RSA key.
El 24 de septiembre de 2010 10:31, Nacho Álvarez nasin...@gmail.comescribió:
I have the engine in a dynamic library and there's not relevant part of the
code. If I overwrite rsa_keygen function and if I do something or nothing
but return 1 I get segmentation fault but it's not my function, my
function ends ok and invokes the return instruction. The example code I
wrote is an example that makes OpenSSL ends with segmentation fault.
I don't know how to get gdb output from a dynamic library or OpenSSL.
2010/9/23 Christian Hohnstaedt christ...@hohnstaedt.de
On Thu, Sep 23, 2010 at 10:08:40AM +0200, Nacho ?lvarez wrote:
That's not the problem, I think, because if the only instruction of the
function is:
int rsa_keygen (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb) {
return 1;
}
I get the segmentation fault when the rsa_keygen ends. But if I return
0
or -1 (errors) OpenSSL reports me error in genrsa and call ends ok (no
segmentation fault or something like that).
What about posting the relevant part of the code?
And the gdb output.
It would help a lot.
Cheers
Christian
2010/9/22 Christian Hohnstaedt christ...@hohnstaedt.de
On Wed, Sep 22, 2010 at 03:41:30PM +0200, Nacho ?lvarez wrote:
Hello everybody
Several months ago I developed an OpenSSL PKCS#11 engine for Windows
XP
and
it worked ok (it was compiled with MinGW).
Now I'm trying to compile it on Linux (Debian 5 with GCC 4.3.1) but
I
have
the next problem:
In the overwritten function *rsa_keygen* (whose signature is *int
rsa_keygen
(RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb)*) always when the
function
ends (after the return instrucction) System reports me *Segmentation
Fault*.
You overwrote you return address on the stack most probably by
accessing a locally declared array out of bounds.
Cheers
Christian
__
OpenSSL Project
http://www.openssl.org
User Support Mailing List
openssl-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: where is the memory being held
Hi, I think I should clarify something here. The app is running in a small device that does not have virtual memory (no swap space) and the memory is limited (256/512 M). In peek connections, it may use up to 90% of the system memory, and when connection goes down, memory usage is not coming down. This leave very little memory for other part of the system, as this app is only a small part of a bigger system. The memory usage is a big concern as it is always running with the box. So far periodically restart the app is not a good solution. -- qun-ying This all seems normal. Virtual memory is not normally considered a scarce resource and unless the consumption is really absurd, it's not worth worrying about. Unless your virtual memory use grows linearly with constant load, it's generally not worth worrying about. If it grows in an exponentially decreasing way with constant load or grows linearly with increasing peak load, I wouldn't worry about it at all. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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: where is the memory being held
On Fri September 24 2010, zhu qun-ying wrote: Hi, I think I should clarify something here. The app is running in a small device that does not have virtual memory (no swap space) and the memory is limited (256/512 M). In peek connections, it may use up to 90% of the system memory, and when connection goes down, memory usage is not coming down. This leave very little memory for other part of the system, as this app is only a small part of a bigger system. The memory usage is a big concern as it is always running with the box. Perhaps you should consider a library intended for use on memory constrained devices? Dropbear is one of the decent choices. There are others. Mike So far periodically restart the app is not a good solution. -- qun-ying This all seems normal. Virtual memory is not normally considered a scarce resource and unless the consumption is really absurd, it's not worth worrying about. Unless your virtual memory use grows linearly with constant load, it's generally not worth worrying about. If it grows in an exponentially decreasing way with constant load or grows linearly with increasing peak load, I wouldn't worry about it at all. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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
FIPS PowerOn self test
Hi, What are the conditions when power-on self tests may fail. We have an application using OpenSSL in FIPS mode and the power on self test has always succeeded. However, today on one of the virtual machines the test failed. What could have possibly lead to this failure? Any ideas? Thanks, Vivek __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Signed Certificates and Revoking the Certs with CRLs
Hi All, Would anyone kindly point me to literature that CLEARLY explains exactly how: Certificates and CRLs may be used in conjunction such that certificate CSRs are generated, signed by an authority, then signed certs downloaded and being used on a system. At a later time, the certificate is revoked in the CRL, the CRL.pem file is downloaded on the system, and then the corresponding cert becomes unusable due to its mention in the CRL. Is there a good place for me to educate myself on this whole mechanism, and a place where it shows exactly how to implement all this with examples... Oh I am running on Linux, with openssl 0.9.8g. Thanks a bunch in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: where is the memory being held
On 9/24/2010 11:05 AM, zhu qun-ying wrote: I think I should clarify something here. The app is running in a small device that does not have virtual memory (no swap space) and the memory is limited (256/512 M). In peek connections, it may use up to 90% of the system memory, and when connection goes down, memory usage is not coming down. This leave very little memory for other part of the system, as this app is only a small part of a bigger system. The memory usage is a big concern as it is always running with the box. So far periodically restart the app is not a good solution. Sounds like OpenSSL wasn't what you wanted. OpenSSL is intended for use on general-purpose computers with virtual memory. It is not designed to return virtual memory to the system, which in your case means it won't return physical memory to the system. Ouch. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Problem to verify a signed file.
From: owner-openssl-us...@openssl.org On Behalf Of Josÿe9 Fernÿe1ndez Sent: Friday, 24 September, 2010 05:04 (It appears your mailer, or perhaps a relay, mangled your name. Sorry.) We are signing files with openssl. We use this command (UNIX machine): openssl smime -sign -binary -outform PEM -in myfile.dat -out myfile.dat.sig -signer cert.pem -inkey keyfile.pem To verify the signed file, we use this other command (PC with Windows): openssl smime -verify -noverify -inform PEM -in myfile.fil.sig -signer cert.pem -content fichero.fil NUL 2myfile.log I assume fichero.fil should be a copy of the original myfile.dat . The file to sing (myfile.dat) is a binary file. This has always worked right, but some days ago, we are getting an error message when we try to verify a signed file. Verification failure 1072:error:21071065:PKSC7 routines:PKCS7_signatureVerify:digest failure:.\crypto \pkcs7\pk7_doit.c:1051: 1072:error:21075069:PKSC7 routines:PKCS7_verify:signature failure:.\crypto\pkcs7 \pk7_smime.c:410: Something is wrong with your file transfer or file. Manually take hashes at both ends and compare them. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Signed Certificates and Revoking the Certs with CRLs
Well, here's the overview: The CRL is a mechanism used by the attesting entity (the CA) to change the validity status of a previously-issued certificate (digitally-provable statement of authority by a particular named entity, i.e. the CA). The certificate, which is best viewed as a record of the act of certifying, is a mathematically-hard transformation of the output of a (universally) lossy compression algorithm over a particular form and style of data structure, and the data structure itself. The function of the data structure is to assert the ownership of a secret number, as witnessed by the ability to perform transformations with the counterpart public number which is included in the data structure. The purpose is to strongly bind the legal identity of the entity applying for the certificate and the public half of an asymmetric keypair (the private key of which is kept private, but evidence of its possession and ability to perform the trapdoor operation is provided). In order to create this, under X.509 there must be a trusted entity (the certifier) whose credential is predistributed in some manner to all systems that will need to rely on the identity claims it makes. (X.509 is limited in two fatal (in my opinion) ways: First, everything is reliant on the Distinguished Name... which isn't distinguished enough to individually distinguish between all entities. Attributes are asserted as relating to a particular DN, not a particular key. Second, it relies on the concept of a single attestor, a single Source of Authority -- when nothing in the Real World can rely upon any single identity document to open an account, it's ludicrous to believe that banks or merchants would accept the single word of a CA as to the identity provided. This causes problems not only for the customer side, but also for the business side: if the Authority that the business chooses to attest to its identity suddenly becomes untrusted, then there is no help but a manual intervention that involves an entire assurance of identity with another CA. No wonder most places choose to go with domain-validated certificates. :( ) To generate keys and obtain certificates, every browser except IE appears to support the old Netscape keygen HTML tag, which creates and puts into a form submission what's called a SPKAC (Signed Public Key And Challenge) to the CA, and the CA may either return a signed certificate immediately, turn down the submission immediately, or hold the submission for manual intervention. The CA is *solely* responsible for what shows up in the certificate. (Best current practice seems to be, the CA drops everything that comes in the same structure (SPKAC or CSR), and generates its own data structure with what it knows to be true, and taking only your public key from the structure you submit after verifying the signature. These certificates have an expiration date, after which they are no longer useful. (i.e., the CA's policy may say something like the private key to any certified public key cannot be in use for more than 24 months before being retired, because we won't accept the risk of it being completely fatigued after that time.) The CRL is one of two standardized mechanisms that the CA has to promulgate the fact that a certificate's status is in abeyance. (The other is OCSP.) For this to work, the end system must update its local copy of the CRL before it can put any trust in it. It is important to note that OpenSSL does not provide a means to *retrieve* CRLs (it doesn't have an HTTP client implementation), but it does provide a mechanism to *use* CRLs that have already been retrieved. (Usually, I use 'curl' or 'wget' to retrieve CRLs that I need to verify against in scripts.) Notably, the name Certificate Revocation List is a bit of a misnomer. It is legitimate for a CA to put a certificate in abeyance, and then at some later point decide that the certificate is actually valid and remove the certificate in question from the CRL, thus indicating that the certificate is in fact good. It's more of a Certificate Status List. (This is at least partly because of necessity -- the EU's Qualified Certificates are invalid until they are accepted by the subscriber. Thus, the Partial CRL profile has a specific bit named: removeFromCrl. For a good place to learn more about how this is supposed to work, I would recommend reading RFC 5280 (OpenSSL doesn't claim conformance to this version, but it's the latest standard for the Internet PKI and explains what the various standardized certifiate extensions mean, as well as describing the CRL processing algorithm). For a very good place to learn about how to implement this with OpenSSL, I would recommend Carillon's excellent How to set up an OpenSSL TEST CA for interoperability with CertiPath document, available at http://www.carillon.ca/library/openssl_testca_howto_1.3.pdf . Also, it's a bit dated, but _Network Security with OpenSSL_ by John Viega, Matt Messier, and
