[erlang-questions] hash_state() and Segmentation Fault

[Valentin Micic]

Good point. Embarrassingly, the version I am running is:

[{<<"OpenSSL">>,9470255,<<"OpenSSL 0.9.8za 5 Jun 2014">>}]

So, there's a culprit.  Thanks! Universe make sense again.

V/

On 15 Apr 2019, at 5:20 PM, Sverker Eriksson wrote:

> In OTP-21.2.7:
> 
> 1> crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ).
> ** exception error: bad argument
>      in function  crypto:hash_final_nif/1
>         called as crypto:hash_final_nif({md5,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>                                                0,0,...>>})
>      in call from crypto:hash_final/1 (crypto.erl, line 395)
> 2> crypto:info_lib().
> [{<<"OpenSSL">>,268443775,<<"OpenSSL 1.0.2g  1 Mar 2016">>}]
> 
> 
> and what does crypto:info_lib() tell you?
> 
> /Sverker
> 
> On mån, 2019-04-15 at 16:51 +0200, Valentin Micic wrote:
>> 
>> On 15 Apr 2019, at 4:09 PM, Sverker Eriksson wrote:
>> 
>>> I amend:
>>> 
>>> OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe crypto:hash_* functions.
>>> 
>> 
>> Thanks Sverker,
>> 
>> I like what you're saying, however that does not correspond to my experience. 
>> I've been performing my tests using Erlang/OTP 21.1, but when I called
>> 
>>>>>> crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} )
>> 
>> therefore, using a fake hash_state() value which tend to cause VM  to bail out reporting a segmentation fault.
>> 
>> Could you please run the line above on one of your run-times (VM) and confirm your assertion.
>> 
>> BTW: Thanks for the info about limiting usage of a hash_state() variable to the VM that created it -- that answered my (somewhat) silly question.
>> 
>> Kind regards
>> 
>> V/
>> 
>> 
>> 
>>> On mån, 2019-04-15 at 15:45 +0200, Sverker Eriksson wrote:
>>>> The crypto:hash_* functions have been type safe since OTP 19 (2016), you can no longer crash the Erlang VM  by passing a fake hash_state argument.
>>>> 
>>>> They are also pure functional. You can save a hash_state and use it as many times you want to fork off different hash caclulations. The only limitation is a hash_state only work in the VM instance that created it.
>>>> 
>>>> /Sverker, Erlang/OTP
>>>> 
>>>> On mån, 2019-04-15 at 12:03 +0200, 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
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190415/be16c2eb/attachment.htm>