[erlang-questions] hash_state() and Segmentation Fault

[Sverker Eriksson]

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/899143e9/attachment.htm>