[erlang-questions] hash_state() and Segmentation Fault

[Valentin Micic]

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.

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