[erlang-questions] hash_state() and Segmentation Fault

[Sverker Eriksson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190415/bb7f30be/attachment.htm>