The documentation says
OpenSSL keeps an internal table of digest algorithms and ciphers. It uses this table to lookup ciphers via functions such as EVP_get_cipher_byname().
OpenSSL_add_all_digests() adds all digest algorithms to the table.
My question is, where is this table stored? How does my code know that this method has executed?...how does it work internally, what if i want more SSL connections and one to have all digests added and one not?
Does anyone know any good documentation for this?
Thank you
The NOTES section of the manual page pretty much sums it up:
A typical application will call OpenSSL_add_all_algorithms() initially and EVP_cleanup() before exiting.
and
The cipher and digest lookup functions are used in many parts of the library. If the table is not initialized several functions will misbehave and complain they cannot find algorithms. This includes the PEM, PKCS#12, SSL and S/MIME libraries. This is a common query in the OpenSSL mailing lists.
So assuming that you are writing a typical application, you will add this to your OpenSSL initialization code:
OpenSSL_add_all_algorithms();
and this to the OpenSSL cleanup code:
EVP_cleanup();
and you are done. You are always responsible for calling these yourself in applications which use OpenSSL. If you want to know how OpenSSL stores the table internally, use the source, Luke.
To control which ciphers are available for a specific SSL context, you would use SSL_CTX_set_cipher_list.
As for better documentation than the manual page, I can recommend "Network Security with OpenSSL" by John Viega, Matt Messier & Pravir Chandra. The book is old and does not cover newer versions of OpenSSL, but most of it is still very applicable.
OpenSSL_add_all_algorithms() is not needed for newer OpenSSL versions and is ignored.
For backward and forward compatibility, use this:
# if OPENSSL_API_COMPAT < 0x10100000L
OpenSSL_add_all_algorithms();
# endif
And
# if OPENSSL_API_COMPAT < 0x10100000L
EVP_cleanup();
# endif
The same applies to OpenSSL_add_all_ciphers() and OpenSSL_add_all_digests().
For more details, see the man page at
https://www.openssl.org/docs/man1.1.0/man3/OpenSSL_add_all_digests.html
This is an old question. The API was deprecated some years ago:
The OpenSSL_add_all_algorithms(), OpenSSL_add_all_ciphers(), OpenSSL_add_all_digests(), and EVP_cleanup(), functions were deprecated in OpenSSL 1.1.0 by OPENSSL_init_crypto().
Reference:
https://www.openssl.org/docs/man1.1.0/man3/OpenSSL_add_all_algorithms.html
Related
I use MAC(Message Authentication Code) with Crypto++ library to secure MANET.
The library provides a lot of MACs algorithms.
I found DMAC in the MAC list and i don't know what does it mean?
Message Authentication Code
Best ragards
Hajji
A bit hidden in the class description is a link:
CBC MAC for Real-Time Data Sources (08.15.1997) by Erez Petrank and Charles Rackoff
Which then points to the paper of which the description reads:
We first present a variant of CBC MAC, called double MAC (DMAC) which handles messages of variable unknown lengths. Computing DMAC on a message is virtually as simple and as efficient as computing the standard CBC MAC on the message. We provide a rigorous proof that its security is implied by the security of the underlying block cipher. Next, we argue that the basic CBC MAC is secure when applied to prefix free message space. A message space can be made prefix free by authenticating also the (usually hidden) last character which marks the end of the message.
Double MAC consists of performing CBC-MAC followed by another CBC-MAC over the result, which should thwart length extension attacks on CBC-MAC.
I haven't heard of it before; I guess everybody uses CMAC instead nowadays. CMAC is more efficient as it only requires one additional run of the block cipher, and requires this up front (during initialization of the cipher).
I want to add an ssl support to an old chat application I wrote years ago. I did a lot of reading on OpenSSL and LibreSSL and I decided to try a new libtls API. I think developers did a really great job on this one.
I found it to be very easy to use - almost no changes to my existing code where required. But here is one thing I need to figure out now:
Back in a day, I was using select() to monitor sockets and recv() to read a data. This was easy, because both of those functions are working on file descriptors.
Now, with libtls, function tls_read() requires a tls context as a first argument. This means I need to search the list of clients to get an appropriate tls context every time I have a descriptor ready to be read. This is not that hard but maybe someone knows a better solution? I will appreciate all comments and code samples.
Unless I'm misreading the documentation, it seems to me that if you create the sockets yourself, and then use tls_connect_fds/tls_connect_socket/tls_accept_fds/tls_accept_socket afterwards, you'll have normal file handles available you can trivially use with select()/poll()/etc. You'd still need to keep around some sort of file descriptor to context mapping to actually issue the tls_read/tls_write once you were ready, but that's just your choice of linked list or hashtable, depending on what language you're using and what stdlib you have available.
I use keySet() api in production. But I know it's not recommended.
So I'd like to change it to new api over version 7.x
It's introduced on official blog.
http://blog.infinispan.org/2014/05/iterate-all-entries-in-cache.html
But I can't figure it out how to use it in Hotrod RemoteCache.
Anyone already tried successfully?
Thanks a lot.
This was answered at https://developer.jboss.org/message/920029?et=watches.email.thread#920029
Radim Vansa said:
Regrettably, this feature is not available yet over Hot Rod. Remote clients have certain lag after embedded-mode features. Map/Reduce and DistributedExecutors over HR are quite close on the roadmap, distributed entry retrievers should follow.
William Burns said:
I also wanted to make sure you are aware that the keySet method is fine to use in the API as outlined [1]. The Cache Javadoc has some more specifics [2]. Basically the methods you should never use are the toArray methods on the collections returned from keySet, entrySet or values. The other methods are done lazily. Note this means the collection isn't a copy like before as well.
Also to note if you do end up using any of the iterators from these bulk methods, you need to make sure to close them properly.
However as Radim pointed out Hot Rod does not have this support yet (embedded only), but should be coming to a new version soon.
[1] http://blog.infinispan.org/2014/11/why-doesnt-mapsize-return-size-of.html
[2] https://docs.jboss.org/infinispan/7.1/apidocs/org/infinispan/Cache.html#entrySet%28%29
First of all, I'm a beginner in the OpenSSL world. I apologize in advance for any basic, barbaric errors.
Consider a flow:
Initialize OpenSSL with engine using hardware (let's call it EngineHW).
Call an OpenSSL function, e.g. X509_sign.
How to check if the function called was performed on the hardware?
How to verify the EngineHW function was called? What if the function is not defined by EngineHW - will OpenSSL fallback to any default engine it has?
The question is related to asserting quality - since I've got the hardware to do crypto for me, I consider using software a regression (at least for the important functions).
Not sure what the purpose of this is. Are you testing that OpenSSL works or are you testing your own code?
It seems you want to do regression testing of OpenSSL and HSM?
However, if you want to test if X509_sign works then remove all software/disk based keys from the test system and check if you can sign something. If you get a valid signature you can be sure it comes from your HSM. If you get null back, it is not.
OpenSSL doesn't fallback to a different sign function and even if it did, it can't sign since it needs a key to sign.
Hope that answered your question.
I'm experimenting with SSL in Erlang, and I've run into a problem.
The device which I'm talking to requires me to set the max send fragment size. In OpenSSL, this would be done with SSL_CTX_ctrl(ctx, SSL_CTRL_SET_MAX_SEND_FRAGMENT, ...).
Is there any way to do this in Erlang?
Erlang does not rely on OpenSSL for its SSL implementation.
Unfortunately, it seems that it currently does not support an option to limit fragment size or RFC 6066's maximum fragment length negotiation. It simply fragments at 16 KB (2^14), the maximum fragment size defined in RFC 2246.
The code that splits fragments is in ssl_record:encode_data/3. Supporting an option like OpenSSL seems trivial to implement, and RFC 6066 negotiation does not seem hard either. You would probably just need to extend connection_state record. Please do not hesitate to submit a patch.