Re: [openssl-users] Guidance on proper usage of OpenSSL_add_all_digests

[chris . gray]

> On Wed, Mar 2, 2016 at 12:27 PM, Neptune  wrote:
> [...]
> You can perform initialization in a static C++ ctor, but it can be
> tricky because the C++ committee has never addressed the problem of
> initialization order across translation units. Also see What's the
> "static initialization order fiasco"?
> (http://www.parashift.com/c++-faq/static-init-order.html).

So static initialisation in Java is not the most capricious and
error-prone mechanism ever invented?  My faith in mankind takes yet
another knock.


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Guidance on proper usage of OpenSSL_add_all_digests

[Thomas Francis, Jr.]

> On Mar 2, 2016, at 12:27 PM, Neptune  wrote:
> 
> Using OpenSSL 1.0.1l
> 
> I just learned the painful way that OpenSSL_add_all_digests() is not a
> thread-safe function. I had been calling this in the constructor of a class
> providing hash functions for multiple threads. My question is, how do I know
> if a thread instantiating my class has called OpenSSL_add_all_digests() or
> not? Is there a way to query OpenSSL for the state of the table? Perhaps
> more importantly, is it a requirement to call this function at all? My test
> application seems quite happy to do SHA1 hashes without calling any of the
> *add_all* functions :-/

You should initialize OpenSSL prior to starting any threads.  Likewise, you 
should then de-initialize it only after all threads (except your main thread, 
of course) have finished.  If you absolutely have to do it inside some 
secondary thread, then initialize a value to tell you if you’ve initialized 
OpenSSL or not and look at it.  If you’re using pthreads, you could put your 
OpenSSL initialization in a single function, and then in each thread, invoke it 
with pthread_once().  That way it’ll never be called more than once.  That 
still leaves you with the issue of cleanup, but that might not matter, 
depending on how you use it.

This is changing with OpenSSL 1.1, but for the better.  IIUC, most users won’t 
need to bother with initialization at all.


> Google searches bring back about a dozen different "proper" ways of
> initializing, so I am asking for some expert guidance.

A lot of the differences come down to personal preference.  You don’t have to 
call OpenSSL_add_all_digests(), depending on what you’re doing, but I’d 
recommend either calling it, or calling EVP_add_digest() for each digest you 
intend to use.  I’d also suggest that if it’s working without either call, then 
perhaps you’re not doing it right. :)  Avoid using any functions like 
SHA1_Init(); use EVP_DigestInit(), instead.  The EVP interfaces are superior, 
especially when you eventually need to change which hashing algorithm to use.

TOM

> Thanks!
> 
> 
> 
> --
> View this message in context: 
> http://openssl.6102.n7.nabble.com/Guidance-on-proper-usage-of-OpenSSL-add-all-digests-tp64243.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
> 

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Guidance on proper usage of OpenSSL_add_all_digests

[Jeffrey Walton]

> Finally, for the crypto components, like SHA... I don't believe they
> need explicit initialization unless you are doing something like
> changing the default implementation from software to an engine. The
> SSL part of the library allows you to explicitly add selected
> algorithms to control what algorithms are used in that portion of the
> library.

My bad.. "Library Initialization | libcrypto Initialization"
(http://wiki.openssl.org/index.php/Library_Initialization#libcrypto_Initialization)
sates you can use either OpenSSL_add_all_ciphers,
OPENSSL_add_all_algorithms_noconf, or you can pick what you want when
initializing crypto portion of the library.

For picking what you want:

void MyLIB_init_crypto(void)
{
EVP_add_cipher(EVP_sha1());
}

The earlier still holds true. Initialize and install lock on the
primary thread. And take care when using static C++ objects.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Guidance on proper usage of OpenSSL_add_all_digests

[Jeffrey Walton]

On Wed, Mar 2, 2016 at 12:27 PM, Neptune  wrote:
> Using OpenSSL 1.0.1l
>
> I just learned the painful way that OpenSSL_add_all_digests() is not a
> thread-safe function. I had been calling this in the constructor of a class
> providing hash functions for multiple threads. My question is, how do I know
> if a thread instantiating my class has called OpenSSL_add_all_digests() or
> not? Is there a way to query OpenSSL for the state of the table? Perhaps
> more importantly, is it a requirement to call this function at all? My test
> application seems quite happy to do SHA1 hashes without calling any of the
> *add_all* functions :-/
>

Generally you want to provide initialization on the primary thread
during program startup. That's when you do things like installing the
locks, too. OpenSSL 1.1.0 adds OPENSSL_init_ssl, but its not clear to
me if it allows you to query subsystem initialization.

You can perform initialization in a static C++ ctor, but it can be
tricky because the C++ committee has never addressed the problem of
initialization order across translation units. Also see What's the
"static initialization order fiasco"?
(http://www.parashift.com/c++-faq/static-init-order.html).

Because of gaps in the C++ language, I usually do it in a c++ class
ctor, but the object resides in main(). On the occasions that the C++
class is instantiated as a static object, I use two techniques to
ensure the order of initialization. The first is object file ordering.
The second is compiler attributes, like "__attribute__ ((init_priority
(250)))" (with Clang/GCC/ICC) and "#pragma init_seg({user | lib})"
(with MSVC).

Unfortunately, there is no reasonable way to audit c++ static
constructor order for quality assurance purposes. Also see How to
verify init_priorty for C++ static object initialization order?
(http://sourceware.org/ml/binutils/2015-09/msg00173.html) on the
Binutils mailing list.

Regardless of how you do it, this is what you want to do:
https://wiki.openssl.org/index.php/Library_Initialization. The short
of this is call the following two functions:

  * SSL_library_init()
  * SSL_load_error_strings()

Finally, for the crypto components, like SHA... I don't believe they
need explicit initialization unless you are doing something like
changing the default implementation from software to an engine. The
SSL part of the library allows you to explicitly add selected
algorithms to control what algorithms are used in that portion of the
library.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Guidance on proper usage of OpenSSL_add_all_digests

[Neptune]

Using OpenSSL 1.0.1l

I just learned the painful way that OpenSSL_add_all_digests() is not a
thread-safe function. I had been calling this in the constructor of a class
providing hash functions for multiple threads. My question is, how do I know
if a thread instantiating my class has called OpenSSL_add_all_digests() or
not? Is there a way to query OpenSSL for the state of the table? Perhaps
more importantly, is it a requirement to call this function at all? My test
application seems quite happy to do SHA1 hashes without calling any of the
*add_all* functions :-/

Google searches bring back about a dozen different "proper" ways of
initializing, so I am asking for some expert guidance.

Thanks!



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Guidance-on-proper-usage-of-OpenSSL-add-all-digests-tp64243.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