TLS authentication for ldap
We are trying to put in place a high availability instance of openLDAP using a 3-node n-way multi master setup. I can telnet to our instance and each individual node through ports 389 and 636. I can use the showcerts command on port 636 and see the certs but wheh I try to do this on port 389 to use TLS I get the following error. root@tntest-batch:~# openssl s_client -msg -showcerts -connect tntest-ldap.oreillyauto.com:389 CONNECTED(0003) TLS 1.1 [length 00dd] 01 00 00 d9 03 02 52 40 41 bf 23 2b ad 2b 86 42 69 20 4d 27 0c f0 77 98 33 d5 f5 62 c9 fd d3 e9 6d c5 23 b4 62 73 00 00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02 01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 01 140330975884960:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 226 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE We have a server that that runs rebuilds and when it fails due to the TLS hand shake failure this is what is in the logs for it. [java] Exception in thread main org.springframework.dao.DataAccessResourceFailureException: Failed to borrow DirContext from pool.; nested exception is org.springframework.ldap.UncategorizedLdapException: Failed to negotiate TLS session; nested exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [java] at org.springframework.ldap.pool.factory.PoolingContextSource.getContext (PoolingContextSource.java:425) [java] at org.springframework.ldap.pool.factory.PoolingContextSource.getReadOnlyContext (PoolingContextSource.java:401) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:287) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:259) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:606) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:524) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:473) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:493) [java] at org.springframework.ldap.core.LdapTemplate.search (LdapTemplate.java:513) [java] at com.oreillyauto.security.dataaccessor.AdminDao.getNewTerritories (AdminDao.java:515) [java] at com.oreillyauto.security.util.TeamNetAuthenticationNightlyJob.updateLocations (TeamNetAuthenticationNightlyJob.java:341) [java] at com.oreillyauto.security.util.TeamNetAuthenticationNightlyJob.nightlyJobNewHireMaintenanceRunDateRange (TeamNetAuthenticationNightlyJob.java:191) [java] at com.oreillyauto.security.util.TeamNetAuthenticationNightlyJob.main (TeamNetAuthenticationNightlyJob.java:146) [java] Caused by: org.springframework.ldap.UncategorizedLdapException: Failed to negotiate TLS session; nested exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [java] at org.springframework.ldap.core.support.AbstractTlsDirContextAuthenticationStrategy.processContextAfterCreation (AbstractTlsDirContextAuthenticationStrategy.java:126) [java] at org.springframework.ldap.core.support.AbstractContextSource.getContext (AbstractContextSource.java:109) [java] at org.springframework.ldap.core.support.AbstractContextSource.getReadOnlyContext (AbstractContextSource.java:125) [java] at org.springframework.ldap.pool.factory.DirContextPoolableObjectFactory.makeObject (DirContextPoolableObjectFactory.java:138) [java] at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject (GenericKeyedObjectPool.java:1179) [java] at org.springframework.ldap.pool.factory.PoolingContextSource.getContext (PoolingContextSource.java:422) [java] ... 12 more [java] Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
RE: TLS authentication for ldap
I can use the showcerts command on port 636 and see the certs but wheh I try to do this on port 389 to use TLS I get the following error. 389 is the plaintext LDAP port; 636 is for LDAP over SSL/TLS so your system is doing the right thing. If you want to force SSL/TLS, then you'll have to configure your directory to not listen on 389. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS authentication for ldap
On Mon, Sep 23, 2013 at 10:54:04AM -0400, Salz, Rich wrote: Another option is to use LDAP's STARTTLS support on port 389. It seems the config to require it is a bit obscure; http://www.openldap.org/lists/openldap-technical/201202/msg00414.html might be useful. Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: TLS authentication for ldap
Another option is to use LDAP's STARTTLS support on port 389. It seems the config to require it is a bit obscure; http://www.openldap.org/lists/openldap-technical/201202/msg00414.html might be useful. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS authentication for ldap
From: Viktor Dukhovni openssl-us...@dukhovni.org To: openssl-users@openssl.org openssl-users@openssl.org Date: 09/23/2013 10:10 AM Subject:Re: TLS authentication for ldap Sent by:owner-openssl-us...@openssl.org On Mon, Sep 23, 2013 at 10:54:04AM -0400, Salz, Rich wrote: Another option is to use LDAP's STARTTLS support on port 389. It seems the config to require it is a bit obscure; http://www.openldap.org/lists/openldap-technical/201202/msg00414.html might be useful. Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org The authentication work on the single server we have which is running an older version of openLDAP. In my packet captures it appears that the older version of openLDAP is presenting the certificate we want it to present. The new version, although it has the same cert installed in the same place it is presenting an older self signed cert that has been removed. The new servers have been rebooted since this change so now I think it's time to hit the opnldap list again and see where this might be cached. Thanks, Eric -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: E42C2600DDF.A4005 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS authentication for ldap
Viktor Dukhovni wrote: On Mon, Sep 23, 2013 at 10:54:04AM -0400, Salz, Rich wrote: Another option is to use LDAP's STARTTLS support on port 389. It seems the config to require it is a bit obscure; http://www.openldap.org/lists/openldap-technical/201202/msg00414.html might be useful. Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. Command-line option of OpenLDAP command-line tools for using StartTLS extended operation on clear-text port 389: -Z Start TLS request (-ZZ to require successful response) Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
RE: TLS authentication for ldap
Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. And less secure. :) If policy is to use SSL/TLS, then the server must enforce it; trusting the clients to do the right thing is bad. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: TLS authentication for ldap
From: Salz, Rich rs...@akamai.com To: openssl-users@openssl.org openssl-users@openssl.org Date: 09/23/2013 10:29 AM Subject:RE: TLS authentication for ldap Sent by:owner-openssl-us...@openssl.org Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. And less secure. :) If policy is to use SSL/TLS, then the server must enforce it; trusting the clients to do the right thing is bad. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Rich, In my wire capture with the LDAP server that is working all application data is being transported via TLSv1 on port 389. But it was my understanding that SSLv3 was going to be the last since TLS is more secure. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: B71BC600D84.A39F4 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS authentication for ldap
On Mon, Sep 23, 2013 at 11:27:06AM -0400, Salz, Rich wrote: Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. And less secure. :) If policy is to use SSL/TLS, then the server must enforce it; trusting the clients to do the right thing is bad. Assuming the policy is a server policy. In general those enforcing TLS security on the server side live in a state of sin, since while the client may go through the motions of doing TLS, nobody can force it to verify the server certificate. To address active attacks, TLS security requires a cooperative client. If the server is trying to protect login credentials against passive intercept, it can restrict access to TLS clients only, but without a zero-knowledge password mechanism that supports channel binding, the server is still at the mercy of the client's willingness to do *authenticated* TLS. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
{resolved}Re: TLS authentication for ldap
From: Viktor Dukhovni openssl-us...@dukhovni.org To: openssl-users@openssl.org openssl-users@openssl.org Date: 09/23/2013 10:40 AM Subject:Re: TLS authentication for ldap Sent by:owner-openssl-us...@openssl.org On Mon, Sep 23, 2013 at 11:27:06AM -0400, Salz, Rich wrote: Note, the above is for enforcing STARTTLS on the server. If the decision is left to the client, the configuration is less opaque. And less secure. :) If policy is to use SSL/TLS, then the server must enforce it; trusting the clients to do the right thing is bad. Assuming the policy is a server policy. In general those enforcing TLS security on the server side live in a state of sin, since while the client may go through the motions of doing TLS, nobody can force it to verify the server certificate. To address active attacks, TLS security requires a cooperative client. If the server is trying to protect login credentials against passive intercept, it can restrict access to TLS clients only, but without a zero-knowledge password mechanism that supports channel binding, the server is still at the mercy of the client's willingness to do *authenticated* TLS. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org The old self-signed certificates had ben renamed by adding .orig to the file name. I deleted those files and the proper certificate is now being presented. Thank you, Eric -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: EE4C6600A53.A30D6 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: using TRNG via /dev/random
Am 22.09.2013 19:27, schrieb starlight.201...@binnacle.cx: No /dev/urandom is a PRNG. /dev/random is a TRNG. Read the code https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=272b98c6455f00884f0350f775c5342358ebb73f /dev/random is a PRNG which blocks when the (crude) entropy estimation of the entropy pool falls below a limit. Besides this there are afaik no big differences between /dev/random and /dev/urandom. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Debugging cause of unable to get local issuer certificate - one cert works, one doesn't
Hi everyone, I'm hitting a unable to get local issuer certificate error on a specific SSL certificate, and I was wondering how I can best debug this? It's via NXLog which uses OpenSSL so a bit disconnected from the underlying library at the moment, and I'm not too familar with OpenSSL. I've exported the full SSL certificate chain for both logs-01.loggly.comand collectors.sumologic.com using Firefox, each into their own pem file. When establishing a connection, the first works fine, the second gives me: SSL certificate verification failed: unable to get local issuer certificate (err: 20) The only difference I can spot is the second is an EV certificate, and is for sumologic.com whereas the first is explicitly *.loggly.com. If I deliberately mis-match the certificates then I get SSL certificate verification failed: self signed certificate in certificate chain (err: 19) so it's definitely something specific to the SumoLogic certificate verification chain as far as I can tell? Any help would be much appreciated. J
RE: Reusing client session question
First, your question is really about a *connection* not a session. For many familiar protocols these are pretty much the same thing, but for SSL they are not. In SSL the session can and often but not always does continue to exist after a connection is closed, and can be reused by subsequent connections, or parallel ones. To your question, it depends on what you are connected to and in particular what protocol(s) that supports or requires. As one everyday example, HTTP/1.0 only allows one request and response per connection; standardly you need a separate connection for each webpage and resource (img, css, etc.). Though for https=SSL those connections can reuse the session. And there were fairly common extensions before 1.1. HTTP/1.1 allows an unlimited number of requests and responses over one connection by default, but either client or server can limit it - to 1, some higher number, or time, or whatever. If you are connecting to your own application, you get to decide when you write that application what it supports. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jim Johnson Sent: Saturday, September 21, 2013 14:45 To: openssl-users@openssl.org Subject: Reusing client session question Is it ok to reuse the client session but just not closing it? I send a SSL_write then a SSL_read command, then I wait 30 seconds and send anther SSL_write and another SSL_Read request. Is this an appropriate way to reuse a connection?
RE: About dgst option
It depends on the type of key used. (Asymmetric) digital signature “algorithms” (schemes) consist of 2 or 3 parts: - the digest algorithm applied to the data - for RSA only, the padding applied to the digest - the public-key algorithm used (RSA, DSA, ECDSA) Commandline dgst allows you to specify the digest, but since you didn’t it defaults to SHA1. It uses the public-key algorithm determined by the key in the key file provided. For RSA, you can specify the padding with -sigopt or it defaults to PKCS1 (v1.5, type 1). Thus with only the options posted, you got SHA1withRSA(PKCS1) dsawithSHA1 or ecdsawithSHA1. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Marco A. Cruz Quevedo Sent: Friday, September 20, 2013 16:47 To: openssl-users@openssl.org Subject: *** Spam *** About dgst option Dear sirs: I use your openssl commandline utility but I need to know, which signing algorithm is used when openssl dgst -sign %key_pem% ... is issued.
Re: using TRNG via /dev/random
At 20:27 9/23/2013 +0200, Richard Könning wrote: /dev/random is a PRNG which blocks when the (crude) entropy estimation of the entropy pool falls below a limit. Besides this there are afaik no big differences between /dev/random and /dev/urandom. In the sense that all TRNG outputs are run through various algorithms that mix and whiten the data to assure uniform statistical distribution, all TRNGs could be called PRNGs. However the crucial difference is that TRNG post-filter output is irreproducible where a pseudo random number generator will predictably generate identical streams of output given the same seed. So Intel's RDRAND is a PRNG in the sense you seem to be invoking. I'll take the heavily reviewed open-source Linux algorithm over Intel's or anyone else's black-box. I believe Linus Torvalds is correct when he says that they know what they are doing. /dev/urandom (in newer kernels) continually re-seeds itself from the common entropy pool but will apply TRNG when demand exceeds supply. My desire is to experiment with having 'openssl' rely on the better quality /dev/random source (enhanced by a higher-volume input such as from a TPM or RDRAND) at the cost of occasional millisecond time-scale delays. From random.c: The two other interfaces are two character devices /dev/random and /dev/urandom. /dev/random is suitable for use when very high quality randomness is desired (for example, for key generation or one-time pads), as it will only return a maximum of the number of bits of randomness (as estimated by the random number generator) contained in the entropy pool. The /dev/urandom device does not have this limit, and will return as many bytes as are requested. As more and more random bytes are requested without giving time for the entropy pool to recharge, this will result in random numbers that are merely cryptographically strong. For many applications, however, this is acceptable. If you can convince the kernel developers that the above statement is incorrect and have a patch accepted to modify the text, I'll abandon my exploration of employing /dev/random. Until then I find the random.c comments authoritative. I certainly can an will dig into the code. Merely posted here in the hope that someone was familiar with the behavior of 'openssl' in the face of blocked requests for random bytes. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Debugging cause of unable to get local issuer certificate - one cert works, one doesn't
Sorry for top-posting but you apparently posted richtext and my new improved Outlook can no longer impoverish text correctly nor reply inline to richtext. Bah. You don't need the full chain(s), only the root(s), since both servers send chain as they should. The difference is that the sumologic chain uses GeoTrust Primary Certification Authority which appears to be both self-signed and (cross)signed by Equifax probably for transition (although 2006 is a while back now) and the server actually sends the cross-signed one. Firefox (at least the current version 24 I can check) has the self-signed version built-in which it uses (and exports). OpenSSL on the contrary will not (yet) override a received cert with a truststore one, so it needs the Equifax root. Which is also in FF 24; under Authorities find Equifax Secure CA, export that and use that. If you really want to know how (as asked) not just what, if you have openssl commandline the easiest way is to run openssl s_client -connect host:port and look at the cert chaining (0 s: and i:, 1 s: and i:, and so on), and in this case compare to what FF displays. If you need the contents of the non-leaf certs (here you don't really) add -showcerts . Note the sumologic leaf cert has Subject CN sumologic.com, but SubjectAlternativeNames correctly specifying other names including collectors.sumologic.com. EV certs aren't allowed to use wildcard names. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of James Crowley Sent: Monday, September 23, 2013 14:28 To: openssl-users@openssl.org Subject: *** Spam *** Debugging cause of unable to get local issuer certificate - one cert works, one doesn't Hi everyone, I'm hitting a unable to get local issuer certificate error on a specific SSL certificate, and I was wondering how I can best debug this? It's via NXLog which uses OpenSSL so a bit disconnected from the underlying library at the moment, and I'm not too familar with OpenSSL. I've exported the full SSL certificate chain for both logs-01.loggly.com and collectors.sumologic.com using Firefox, each into their own pem file. When establishing a connection, the first works fine, the second gives me: SSL certificate verification failed: unable to get local issuer certificate (err: 20) The only difference I can spot is the second is an EV certificate, and is for sumologic.com whereas the first is explicitly *.loggly.com. If I deliberately mis-match the certificates then I get SSL certificate verification failed: self signed certificate in certificate chain (err: 19) so it's definitely something specific to the SumoLogic certificate verification chain as far as I can tell? Any help would be much appreciated. J
Re: Debugging cause of unable to get local issuer certificate - one cert works, one doesn't
Thank you so much, I would never have figured that out in a million years! It works perfectly following those instructions. And always good to know the how in case I trip over it again, much appreciated. Apologies for the richtext, I blame Google for that one... On 23 September 2013 22:25, Dave Thompson dthomp...@prinpay.com wrote: Sorry for top-posting but you apparently posted richtext and my new “improved” Outlook can no longer impoverish text correctly nor reply inline to richtext. Bah. ** ** You don’t need the full chain(s), only the root(s), since both servers send chain as they should. The difference is that the sumologic chain uses “GeoTrust Primary Certification Authority” which appears to be both self-signed and (cross)signed by Equifax probably for transition (although 2006 is a while back now) and the server actually sends the cross-signed one. Firefox (at least the current version 24 I can check) has the self-signed version “built-in” which it uses (and exports). OpenSSL on the contrary will not (yet) override a received cert with a truststore one, so it needs the Equifax root. Which is also in FF 24; under Authorities find Equifax Secure CA, export that and use that. ** ** If you really want to know how (as asked) not just what, if you have openssl commandline the easiest way is to run openssl s_client -connect host:port and look at the cert chaining (0 s: and i:, 1 s: and i:, and so on), and in this case compare to what FF displays. If you need the contents of the non-leaf certs (here you don’t really) add -showcerts . ** ** Note the sumologic leaf cert has Subject CN sumologic.com, but SubjectAlternativeNames correctly specifying other names including collectors.sumologic.com. EV certs aren’t allowed to use wildcard names. ** ** ** ** *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *James Crowley *Sent:* Monday, September 23, 2013 14:28 *To:* openssl-users@openssl.org *Subject:* *** Spam *** Debugging cause of unable to get local issuer certificate - one cert works, one doesn't ** ** Hi everyone, ** ** I'm hitting a unable to get local issuer certificate error on a specific SSL certificate, and I was wondering how I can best debug this? It's via NXLog which uses OpenSSL so a bit disconnected from the underlying library at the moment, and I'm not too familar with OpenSSL. ** ** I've exported the full SSL certificate chain for both logs-01.loggly.comand collectors.sumologic.com using Firefox, each into their own pem file. When establishing a connection, the first works fine, the second gives me: ** ** SSL certificate verification failed: unable to get local issuer certificate (err: 20) ** ** The only difference I can spot is the second is an EV certificate, and is for sumologic.com whereas the first is explicitly *.loggly.com. If I deliberately mis-match the certificates then I get ** ** SSL certificate verification failed: self signed certificate in certificate chain (err: 19) ** ** so it's definitely something specific to the SumoLogic certificate verification chain as far as I can tell? ** ** Any help would be much appreciated. ** ** J ** ** -- --- James Crowley CTO, FundApps - a new generation in financial services software - http://www.fundapps.co/ Founder, developerFusion - the global developer community - http://www.developerfusion.com/ linkedin: http://linkedin.com/in/jamescrowley twitter: http://twitter.com/jamescrowley
PKCS7 encryption failed when processing concurrent large files (1.6G)
Dear all,
I wrote a function like this:
DLL_INT ECryptEncryptData(char* certFile, char* dataFile, char*
encryptedFile, char* errMsg, int errMsgLen)
{
static char* func = ECryptEncryptData;
int rc = 0;
char msg[MSG_LEN];
BIO *in = NULL, *out = NULL;//, *tbio = NULL;//, *dout = NULL;
BIO *bio_err_out = NULL;
X509 *rcert = NULL;
STACK_OF(X509) *recips = NULL;
CMS_ContentInfo *cms = NULL;
EVP_PKEY *publickey = NULL;
EVP_CIPHER *eAlgt = NULL;
int flags = CMS_BINARY;// | CMS_STREAM;// | CMS_DETACHED;
if (errMsg == NULL || errMsgLen = 0) {
WriteLog(ERROR, %s[%d] invalid input\n, func, __LINE__);
return -1;
}
errMsg[0] = 0;
printf_s(%s[%d] Infor dataFile[%s] encryptedFile[%s]\n, func,
__LINE__, dataFile, encryptedFile);
//OpenSSL_add_all_algorithms();
//ERR_load_crypto_strings();
eAlgt = (EVP_CIPHER*)EVP_des_ede3_cbc();
/* Read in recipient certificate */
if ((publickey = getPublicKey(certFile, rcert, msg, sizeof(msg), rc))
== NULL) {
sprintf_s(errMsg, errMsgLen, %s[%d] getPublicKey fail %s\n, func,
__LINE__, msg);
goto cleanup;
}
else {
EVP_PKEY_free(publickey);
}
/* Create recipient STACK and add recipient cert to it */
if ((recips = sk_X509_new_null()) == NULL || !sk_X509_push(recips,
rcert)) {
sprintf_s(errMsg, errMsgLen, %s[%d] sk_X509_new_null fail\n,
func, __LINE__);
goto cleanup;
}
/* sk_X509_pop_free will free up recipient STACK and its contents
* so set rcert to NULL so it isn't freed up twice.
*/
rcert = NULL;
/* Open content being encrypted */
if ((in = BIO_new_file(dataFile, r)) == NULL) {
sprintf_s(errMsg, errMsgLen, %s[%d] BIO_new_file fail\n, func,
__LINE__);
goto cleanup;
}
/* encrypt content */
else if ((cms = CMS_encrypt(recips, in, eAlgt, flags)) == NULL) {
sprintf_s(errMsg, errMsgLen, %s[%d] CMS_encrypt_WithHeader
fail\n, func, __LINE__);
goto cleanup;
}
else if ((out = BIO_new_file(encryptedFile, wb)) == NULL) {
sprintf_s(errMsg, errMsgLen, %s[%d] BIO_new_file fail\n, func,
__LINE__);
goto cleanup;
}
/* Write out S/MIME message */
else if (!i2d_CMS_bio_stream(out, cms, in, flags)) {
sprintf_s(errMsg, errMsgLen, %s[%d] i2d_CMS_bio_stream fail\n,
func, __LINE__);
goto cleanup;
}
cleanup:
if (strlen(errMsg)) {
WriteLog(ERROR, %s, errMsg);
if (!rc)
rc = -1;
bio_err_out = OpenLog();
}
if (cms)
CMS_ContentInfo_free(cms);
if (rcert)
X509_free(rcert);
if (recips)
sk_X509_pop_free(recips, X509_free);
if (in)
BIO_free(in);
if (out)
BIO_free(out);
/*if (dout)
BIO_free(dout);*/
/*if (tbio)
BIO_free(tbio);*/
if (bio_err_out) {
if (MEM_LEAK_CHEK)
CRYPTO_mem_leaks(bio_err_out);
ERR_print_errors(bio_err_out);
BIO_free(bio_err_out);
}
return rc;
}
I export it to an external dll for other application to call it.
Everything is OK for a single call to it. But when it be called concurrent
in multi threads (one thread proceeded a difference file), the return
encrypted file will fail (the file size some times has 0 bytes...).
I also try not use it in multi threads. I ran many applications at the same
time to encrypt multiple files (one application proceeded a difference
file) but it still failed.
I very much appreciate for any help
Thank you,
Vu Le
Re: using TRNG via /dev/random
On Mon, Sep 23, 2013 at 12:59 PM, starlight.201...@binnacle.cx wrote: At 20:27 9/23/2013 +0200, Richard Könning wrote: /dev/random is a PRNG which blocks when the (crude) entropy estimation of the entropy pool falls below a limit. Besides this there are afaik no big differences between /dev/random and /dev/urandom. In the sense that all TRNG outputs are run through various algorithms that mix and whiten the data to assure uniform statistical distribution, all TRNGs could be called PRNGs. However the crucial difference is that TRNG post-filter output is irreproducible where a pseudo random number generator will predictably generate identical streams of output given the same seed First, whenever someone talks about true random numbers, I assume they are kidding - I know of no cryptographers who use that term. It's a meaningless phrase. Cryptographically useful random number generators possess the desired characteristics - no detectable bias in the bitstream, passing all the usual FIPS tests, etc., as well as forward and backward secrecy, etc. and make use of all available sources of entropy. Unless you're talking about a naive implementation of a LFSR or somesuch, PRNGs don't have a single seed. I'll repeat myself - the fact that the /dev/random implementation you're using blocks is a serious design flaw. Secondly, presuming that the current process (openssl-based) is permitted to perform a blocking read on a constrained system resource is similarly misguided - there may be other processes that want random bits, too. - M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: using TRNG via /dev/random
At 12:59 9/23/2013 -0700, Michael Sierchio wrote: I'll repeat myself - the fact that the /dev/random implementation you're using blocks is a serious design flaw. Convince Linus, the GPG developers et al.--not me. Till then I respect their view as embodied by the latest implementation of random.c. Perhaps this bleeding-edge analysis will be accepted by the cryptographic community and Linux will evolve as a result. I'm perfectly fine with that. http://eprint.iacr.org/2013/338.pdf But as it is a Free Country I'll experiment with /dev/random and other sources of randomness. You seem a bit overworked about it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
