[erlang-questions] hash_state() and Segmentation Fault

[Hans Nilsson R]

OTP still depends on a third-party cryptolib, OpenSSL or LibreSSL. We have no plans on including a cryptolib into OTP.
/Hans

On 4/15/19 4:56 PM, Valentin Micic wrote:
> Thanks Hans,
> 
> For some reason, I've been under impression that newer versions of Erlang/OTP (19.x and higher) no longer have a dependency on (third party) OpenSSL library.
> Was I wrong to think that?
> 
> Kind regards
> 
> V/
> 
> On 15 Apr 2019, at 2:54 PM, Hans Nilsson R wrote:
> 
>> The hash_state() is just an Erlang reference.  It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib.
>>
>> The area is allocated by enif_alloc_resource  (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page)
>>
>> Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html  section "Resource objects".
>>
>> /Hans
>>
>> On 4/15/19 12:03 PM, Valentin Micic wrote:
>>> Hmmm… I may need to restate the question:
>>>
>>> Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions?
>>>
>>> Thanks in advance.
>>>
>>> V/
>>>
>>> On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote:
>>>
>>>> Hi, 
>>>>
>>>> I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations.
>>>> Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state()  are given.
>>>>
>>>> The results are interesting.
>>>>
>>>> A call to,  say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or 
>>>> erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed
>>>> crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} )
>>>>
>>>> will all produce:
>>>>
>>>> <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>>
>>>>
>>>> Presumably this may be due to some default value that has been used for all invalid values for hash_sate().
>>>>
>>>> However, a call using a fake (yet "non-zero") value in  crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} )  results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?).
>>>>
>>>> As it appears that some internal tests are performed in order to verify the hash_state() value, would  it possible to extend these test to cover other values without imposing unnecessary performance penalty?
>>>>
>>>> Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)… in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values?
>>>>
>>>> Kind regards
>>>>
>>>> V/
>>>>
>>>> (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library.
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4161 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190415/5ecaad81/attachment.bin>