Re: [openssl-users] Errors in building 1.0.2f

2016-02-11 Thread Matt Caswell


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

2016-02-11 Thread Jakob Bohm

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

2016-02-11 Thread cloud force
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

2016-02-11 Thread Lloyd
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

2016-02-11 Thread Lloyd
Thanks, The problem is solved when compiled and linked with "applink.c"

On Thu, Feb 11, 2016 at 5:05 PM, Lloyd  wrote:

> 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

2016-02-11 Thread R-D intern
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

2016-02-11 Thread Valerie Anne Fenwick


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

2016-02-11 Thread cloud force
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 force 
wrote:

> 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

2016-02-11 Thread Jakob Bohm

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

2016-02-11 Thread Alex Chen
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

2016-02-11 Thread Jakob Bohm

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

2016-02-11 Thread Jakob Bohm

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

2016-02-11 Thread Nounou Dadoun
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

2016-02-11 Thread cloud force
Anyone saw these errors before?

On Wed, Feb 10, 2016 at 5:34 PM, cloud force 
wrote:

> 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

2016-02-11 Thread cloud force
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