Re: [openssl-users] Errors in building 1.0.2f
On 11/02/16 01:03, Alex Chen wrote: > I tried to build openssl 1.0.2f on MacOS with the following > configuration options "Configure no-bf" but it failed because there is > no header file blowfish.h in include/openssl directory. > This does not happen in 1.0.2d where include/openssl/blowfish.h is a > symbolic link to ../../crypto/bf/blowfish.h. > This is true for idea, cast, jpake, camellia, too. > > What has changed? Configure should have instructed you to run "make depend", i.e. mine says: *** Because of configuration changes, you MUST do the following before *** building: make depend Did you run it? Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode errors
On 12/02/2016 03:45, cloud force wrote: Hi, I built the FIPS capable OpenSSL library on Ubuntu 12.04. When I run the command "OPENSSL_FIPS=1 openssl ciphers", I saw the following error: 140073969415840:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: I tried few other openssl commands under the FIPS mode and got all the same error messages. The non-FIPS mode was working fine. What is the above error mean and what could have caused this error? This is the most severe FIPS error code, it means one of 3 things: 1. (official reason for this error code): Someone illegally modified the FIPS validated crypto code after it was compiled, do not use this computer until the cause has been thoroughly investigated and corrected. 2. (much more likely): The file containing the FIPS code (either lib/libcrypto.so.1.0.0 or the program you ran) was relocated to a different memory address this time than back when you ran fipsld to set the checksum (fingerprint). 3. (sometimes): You forgot to run fipsld to set the checksum (fingerprint). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode errors
Hi Jakob, This is the most severe FIPS error code, it means one of > 3 things: > > 1. (official reason for this error code): Someone illegally > modified the FIPS validated crypto code after it was > compiled, do not use this computer until the cause has > been thoroughly investigated and corrected. > > 2. (much more likely): The file containing the FIPS code > (either lib/libcrypto.so.1.0.0 or the program you ran) > was relocated to a different memory address this time > than back when you ran fipsld to set the checksum > (fingerprint). > If this is the case, how should I fix this problem? > > > 3. (sometimes): You forgot to run fipsld to set the > checksum (fingerprint). > At what point during the build should the fipsld be run? > > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Thanks, Rich -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Win32 - PEM_read_PrivateKey crash
Hi, I have downloaded prebuilt version of openssl for windows. I am running on Windows 7 64bit, Using Visual Studio 2010, generating 32bit binary. When I run a simple application which calling "PEM_read_PrivateKey" it crashes with error "OPENSSL_Uplink(505D6000,08): no OPENSSL_Applink" What could be the reason for this? Any hint is greatly appreciated. Thanks, Lloyd The following is my code - int main() { EVP_PKEY *privkey; FILE *fp; RSA *rsakey; OpenSSL_add_all_algorithms(); privkey = EVP_PKEY_new(); fp = fopen ("G:\\temp\\mykey.pem", "r"); //File exists and it opens PEM_read_PrivateKey( fp, , NULL, NULL); //CRASH fclose(fp); ... } -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Win32 - PEM_read_PrivateKey crash
Thanks, The problem is solved when compiled and linked with "applink.c" On Thu, Feb 11, 2016 at 5:05 PM, Lloydwrote: > Hi, > > I have downloaded prebuilt version of openssl for windows. I am running on > Windows 7 64bit, Using Visual Studio 2010, generating 32bit binary. > > When I run a simple application which calling "PEM_read_PrivateKey" it > crashes with error "OPENSSL_Uplink(505D6000,08): no OPENSSL_Applink" > > What could be the reason for this? Any hint is greatly appreciated. > > Thanks, > Lloyd > > The following is my code - > > int main() { >EVP_PKEY *privkey; >FILE *fp; >RSA *rsakey; > >OpenSSL_add_all_algorithms(); > >privkey = EVP_PKEY_new(); >fp = fopen ("G:\\temp\\mykey.pem", "r"); //File exists and it opens >PEM_read_PrivateKey( fp, , NULL, NULL); //CRASH > >fclose(fp); > > ... > > } > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] regarding SSL security
Hello , I am a Masters student and currently working on a project related to security. I have certain queries regarding ssl security. It would be of great use to me if some of my queries get clarified. The following is listed as: 1. How do I prove that ECC 256 bit key is equivalently strong to RSA 2048 bit key? 2. What all types of threats could be used for testing the above question? 3.The paper has listed Openssl library can be used for enabling ssl security , certificate generation and management. I have created an ECC certificate that works fine but such a certificate shows "Invalid digital signature "message on the certificate. The elliptic curve used for certificate generation is one amongst the named curves supported by Openssl and recommended by NIST-suite B. How can that be resolved? 4.The Openssl library has certificate verification method that checks the certificate validity w.r.t validity period, certificate chain depth, etc, then why is a Certificate Revocation List or an OCSP needed, in a sense if the verification is already done, then why should invalid certificates be revoked and verification be done on the basis of CRL? 5. Is there any other approach for client authentication in SSL other than certificates approach? 6. Is ssl security suitable enough for securing connections to server in control and monitoring systems? How can client authentication be done for such systems using SSL protocol? 7.If CRLs are to be used, then how will the CA know about the private key being compromised so that it can revoke the certificate considering it being forged? Thanks and regards, Suman Patro -- View this message in context: http://openssl.6102.n7.nabble.com/regarding-SSL-security-tp63504.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
Hi Jakob - On 11/22/15 08:17 PM, Jakob Bohm wrote: On 20/11/2015 23:26, Short, Todd wrote: While I am all for simplicity, I also think that removing functionality is a “bad idea”. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest following the 80/20 rule (sometimes the 95/5 rule): Those “who care” (the minority) about the ciphers can re-enable them and rebuild the library. Those “who don’t care” (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity. You all seem to misunderstand the fundamental release engineering issues involved. 1. Very shortly after you release OpenSSL 1.1.0, many distributions and pointy haired managers will blindly switch to the new version as the only version available. This will not at all await the "end of support" for OpenSSL 1.0.x . So breaking changes will cause harm much sooner than you claim. As one of those pointy haired managers, I have to say that this scenario is simply not possible with the ABI incompatibility between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will have to be updated, too. (unless I'm completely misunderstanding something). So, most likely we're looking at a universe where both will coexist for awhile (that seems to match up with OpenSSL's support plans as well). Think of this like when OpenSSL went from 0.9.8 to 1.0.0. Both co-existed for quite awhile. 2. Because of the need to easily keep up with routine security updates to OpenSSL, it is highly impractical to maintain locally reconfigured build scripts and patches, though some of us have no choice (and are still struggling with the massively huge and disorganized code reformatting in the middle of the 1.0.1 security update series). I do not envy this work, but we're talking about a security toolkit - it should not stay in the past. It's, quite simply, dangerous to do so. 3. When distributions upgrade OpenSSL, many applications that have not been actively and deliberately ported to the new OpenSSL version will be blindly recompiled with the new versions, and if they break, random developers with no understanding of either the application, OpenSSL or even security will do ill-informed rushed patches to try to undo the breakage you caused. Sadly, that happens when any toolkit updates. 4. OpenSSL is THE primary crypto library for the FOSS universe. You may be volunteers, but you are working on a massively important piece of software, not some random optional library. Yes, but they are still allowed to change for the better. GnuTLS did this as well, between their 2.x release and 3.x. There is precendence. It is not pain free, but it is what we all need to do to make a better and safter internet. Bad choices made now will haunt us for another 10+ years. Valerie 5. In these times of panic and marshal law, it is essential that the key resources for open source crypto remain unrestrained by the politics of any single country, such that the sudden outlawing of crypto in the current home of the maintainers does not prevent the project from being continued by a different team in a different country. This makes it essential not to tie any legal or technical aspect to a single place, country, political alliance, company or person. It is also critical to avoid any and all legal ties to the historically most problematic jurisdictions, such as the US. So don't pay people through any US bank accounts, foundations or legal entities. Don't keep any technical assets (such as repositories or mail archives) in one country. Don't create legal documents that tie any license permissions to any specific country or organization. These same considerations exclude any of the US based libraries and forks from being relevant outside that country. 6. All of this requires a lot more caution and a lot less arrogance from the people making decisions about changes in the OpenSSL library and project. Enjoy Jakob Valerie -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL lib build errors
I checked the libcrypto.so which was built right before this, and was able to find these symbols. Still not sure why these errors showed up. Any suggestions and possible solutions are greatly appreciated. On Wed, Feb 10, 2016 at 5:34 PM, cloud forcewrote: > Hi All: > > I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu > 12.04 debian meta file). > > The Ubuntu package uses Configure for configuring the source tree with the > following parameters: > > > > *ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS = --prefix=/usr > --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea > no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 $(ARCH_CONFARGS)* > > > I ran into the following errors near the end of the build: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \ > shlib_target="linux-shared"; \elif [ -n "libcrypto" ]; then \ > FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC > FIPSLD_CC; \fi; \LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \make > -f ../Makefile.shared -e \APPNAME=openssl OBJECTS="openssl.o > verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o > errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o > ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o > s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o > nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o > rand.o engine.o ocsp.o prime.o ts.o srp.o" \LIBDEPS=" $LIBRARIES > -ldl -lz" \link_app.${shlib_target}make[3]: Entering directory > `/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function > `speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219: > undefined reference to > `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220: > undefined reference to > `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221: > undefined reference to > `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224: > undefined reference to > `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225: > undefined reference to > `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226: > undefined reference to > `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229: > undefined reference to > `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230: > undefined reference to > `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231: > undefined reference to > `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237: > undefined reference to > `private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240: > undefined reference to > `private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243: > undefined reference to > `private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249: > undefined reference to > `private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252: > undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit > status* > > > Any suggestions and possible solutions are greatly appreciated. > > -- > Thanks, > Rich > > -- Thanks, Rich -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] regarding SSL security
On 11/02/2016 19:31, R-D intern wrote: Hello , I am a Masters student and currently working on a project related to security. I have certain queries regarding ssl security. It would be of great use to me if some of my queries get clarified. The following is listed as: 1. How do I prove that ECC 256 bit key is equivalently strong to RSA 2048 bit key? This is so hard that noone has done it yet. Experienced experts have made estimates based on the best known theoretical attack against each and comparing the (extreme/impossibly large) amount of computer power to break them. For example one of the relevant attacks against 2048 bit RSA is to use the best known algorithm to factor a 2048 bit number known to be the multiple of two large primes. This requires a certain number of fundamental computer resources (CPU cycles and memory bytes). A similar consideration can be made for the best algorithm to find the secret multiplier (private key) from the ECC 256-p point published as the public key. Next adjust both numbers by how much those algorithms are going to improve over the time the private key has to be kept secret (for SSL/TLS session signatures with ephemeral DH session key exchange), this is just the time from certificate issuance/key generation until the certificate expires. But for some other uses this is the time until signed digital documents (such as deeds of ownership to a house) are no longer important enough to protect against forgery, usually many decades. Especially that last step is very much a matter of opinion, and thus different researchers disagree. For instance Certicom, the original main proponents of ECC crypto, published tables that claimed a much larger RSA key would be needed to get the same security as 256 bit ECC. 2. What all types of threats could be used for testing the above question? See above. 3.The paper has listed Openssl library can be used for enabling ssl security , certificate generation and management. I have created an ECC certificate that works fine but such a certificate shows "Invalid digital signature "message on the certificate. The elliptic curve used for certificate generation is one amongst the named curves supported by Openssl and recommended by NIST-suite B. How can that be resolved? Either you did something wrong when generating the certificate, or you are testing with a software tool that doesn't support that particular form of ECC signature. Note that ECC keys and signatures can refer to the chosen curve in one of two ways ("named curve" or explicit curve description), OpenSSL only accepts the "named curve" form as input. 4.The Openssl library has certificate verification method that checks the certificate validity w.r.t validity period, certificate chain depth, etc, then why is a Certificate Revocation List or an OCSP needed, in a sense if the verification is already done, then why should invalid certificates be revoked and verification be done on the basis of CRL? The revocation check is to check if something bad happened after the certificate was generated and signed by the issuing CA. Typical examples include: - The legitimate certificate holder had her private key stolen ("compromised") or at least found herself in a situation where she could no longer be sure if someone has an illegetimate copy. - The facts stated in the certificate are no longer true, for instance, if the certificate states that the certificate holder is a resident of city X, but has since moved to city Y. - The CA that issued the certificate finds out it did so in error, e.g. it accidentally issued it to the wrong person, or it issued an SHA-1 based certificate after the official deadline for ceasing all such issuance (This has happened sevaral times in the last 40 days). 5. Is there any other approach for client authentication in SSL other than certificates approach? Yes, the full SSL protocol also supports various password based methods, but they are considered less secure for most purposes. 6. Is ssl security suitable enough for securing connections to server in control and monitoring systems? How can client authentication be done for such systems using SSL protocol? Depends how important security of that communication is, and how strong the minimum SSL settings are configured. For example if the control connection is for a large industrial plant of a type where deliberately issuing the wrong control commands can generate a major disaster (Bopal sized), then as long as people are living next to the factory or working inside the factory, it might not be secure to allow such control to be done from outside the factory, no matter how secure the connection is (the problem is that the person pushing the buttons isn't risking his own life too). But as the potential risks get smaller, the level of security of the connection can be weighed against the dangers that would result from compromising the connection. Assessing this involves not
Re: [openssl-users] Errors in building 1.0.2f
Yes, I did. It still failed. I manually made the symbolic links and the compilation completed without problem. But this should have been taken care of by Configure, should it not? Alex On 2/11/16, 1:07 AM, "openssl-users on behalf of Matt Caswell"wrote: > > >On 11/02/16 01:03, Alex Chen wrote: >> I tried to build openssl 1.0.2f on MacOS with the following >> configuration options "Configure no-bf" but it failed because there is >> no header file blowfish.h in include/openssl directory. >> This does not happen in 1.0.2d where include/openssl/blowfish.h is a >> symbolic link to ../../crypto/bf/blowfish.h. >> This is true for idea, cast, jpake, camellia, too. >> >> What has changed? > >Configure should have instructed you to run "make depend", i.e. mine says: > >*** Because of configuration changes, you MUST do the following before >*** building: > > make depend > >Did you run it? > >Matt >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
Someone picked up an old dead thread, but I'll make some brief responses. On 11/02/2016 20:49, Valerie Anne Fenwick wrote: Hi Jakob - On 11/22/15 08:17 PM, Jakob Bohm wrote: On 20/11/2015 23:26, Short, Todd wrote: While I am all for simplicity, I also think that removing functionality is a “bad idea”. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest following the 80/20 rule (sometimes the 95/5 rule): Those “who care” (the minority) about the ciphers can re-enable them and rebuild the library. Those “who don’t care” (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity. You all seem to misunderstand the fundamental release engineering issues involved. 1. Very shortly after you release OpenSSL 1.1.0, many distributions and pointy haired managers will blindly switch to the new version as the only version available. This will not at all await the "end of support" for OpenSSL 1.0.x . So breaking changes will cause harm much sooner than you claim. As one of those pointy haired managers, I have to say that this scenario is simply not possible with the ABI incompatibility between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will have to be updated, too. (unless I'm completely misunderstanding something). So, most likely we're looking at a universe where both will coexist for awhile (that seems to match up with OpenSSL's support plans as well). This shows you are not pointy-haired enough to fit this example. Think of this like when OpenSSL went from 0.9.8 to 1.0.0. Both co-existed for quite awhile. However the differences between 0.9.8 and 1.0.0 were much smaller than the upcoming differences between 1.0.x and 1.1.x . They are basically removing lots of functionality for very little gain. 2. Because of the need to easily keep up with routine security updates to OpenSSL, it is highly impractical to maintain locally reconfigured build scripts and patches, though some of us have no choice (and are still struggling with the massively huge and disorganized code reformatting in the middle of the 1.0.1 security update series). I do not envy this work, but we're talking about a security toolkit - it should not stay in the past. It's, quite simply, dangerous to do so. But it should not do things that leave past "customers" unprotected because they can no longer use the current but incompatible toolkit. Because that in and of itself is also very dangerous. 3. When distributions upgrade OpenSSL, many applications that have not been actively and deliberately ported to the new OpenSSL version will be blindly recompiled with the new versions, and if they break, random developers with no understanding of either the application, OpenSSL or even security will do ill-informed rushed patches to try to undo the breakage you caused. Sadly, that happens when any toolkit updates. Yes, but some updates are more likely to cause such harm than others. Thisis the whole reason the entire computer industryis so keen on backwards compatibility. 4. OpenSSL is THE primary crypto library for the FOSS universe. You may be volunteers, but you are working on a massively important piece of software, not some random optional library. Yes, but they are still allowed to change for the better. GnuTLS did this as well, between their 2.x release and 3.x. There is precendence. It is not pain free, but it is what we all need to do to make a better and safter internet. Bad choices made now will haunt us for another 10+ years. I was arguing that they *are* making bad choices now. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] no version information available error
On 10/02/2016 22:46, cloud force wrote: Hi Everyone, I installed the FIPS capable openssl library (which was built by myself) on my Ubuntu linux box. For some reason, I keep running into the following errors whenever I run ssh related command: ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by ssh) The same error happens when I ran openssl command such as the following: linux-fips@ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by openssl) openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by openssl) openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0) openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0) The Debian-family (includes Ubuntu) standard OpenSSL shared libraries is built in a special way to include "version tags" in the resulting .so files, and all the openssl-needing binaries in Debian/Ubuntu/etc. produce the error message above if you install copies of those libraries without those extra "version tags". There are two alternative ways to solve this: A) Build your FIPS-cabable OpenSSL (not the FIPScanister) with all the extra steps and patches in the Ubuntu OpenSSL source package (.dsc etc.), just adding the FIPS canister. Note that some of the patches in the source package are backports of the security fixes included in the latest OpenSSL versions, you'll probably have to figure out the details yourself (unless Kurt Roeckz posts a recipe somewhere). B) Patch your FIPS-capable OpenSSL makefile (not the FIPScanister makefile) to use a different .so-version, such as .so.1.0.2 . Then your private openssl build will not be used by the prepackaged software while software explicitly compiled against your locally build OpenSSL will not accidentally pick up the standard non-FIPS OpenSSL. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] 2-key vs 3-key 3DES
I've just been reading about recommended and deprecated encryption and tripped over a nist document (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf) that distinguishes between 2key and 3key 3DES saying that the former is deprecated after 2015 but the latter is still acceptable. Is this distinguishable in openssl? I.e. if we negotiate TLS_RSA_WITH_3DES_EDE_CBC_SHA does it always use the 3-key version? (I'm experimenting running NeXpose against an embedded device to look for security holes and it complained about DES (we only use 3DES) and CBC - odd!) Thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 | avigilon.com Follow Twitter | Follow LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL lib build errors
Anyone saw these errors before? On Wed, Feb 10, 2016 at 5:34 PM, cloud forcewrote: > Hi All: > > I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu > 12.04 debian meta file). > > The Ubuntu package uses Configure for configuring the source tree with the > following parameters: > > > > *ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS = --prefix=/usr > --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea > no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 $(ARCH_CONFARGS)* > > > I ran into the following errors near the end of the build: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \ > shlib_target="linux-shared"; \elif [ -n "libcrypto" ]; then \ > FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC > FIPSLD_CC; \fi; \LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \make > -f ../Makefile.shared -e \APPNAME=openssl OBJECTS="openssl.o > verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o > errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o > ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o > s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o > nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o > rand.o engine.o ocsp.o prime.o ts.o srp.o" \LIBDEPS=" $LIBRARIES > -ldl -lz" \link_app.${shlib_target}make[3]: Entering directory > `/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function > `speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219: > undefined reference to > `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220: > undefined reference to > `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221: > undefined reference to > `private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224: > undefined reference to > `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225: > undefined reference to > `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226: > undefined reference to > `private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229: > undefined reference to > `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230: > undefined reference to > `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231: > undefined reference to > `private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237: > undefined reference to > `private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240: > undefined reference to > `private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243: > undefined reference to > `private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249: > undefined reference to > `private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252: > undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit > status* > > > Any suggestions and possible solutions are greatly appreciated. > > -- > Thanks, > Rich > > -- Thanks, Rich -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] FIPS mode errors
Hi, I built the FIPS capable OpenSSL library on Ubuntu 12.04. When I run the command "OPENSSL_FIPS=1 openssl ciphers", I saw the following error: 140073969415840:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: I tried few other openssl commands under the FIPS mode and got all the same error messages. The non-FIPS mode was working fine. What is the above error mean and what could have caused this error? -- Thanks, Rich -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users