<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 15 Apr 2019, at 4:09 PM, Sverker Eriksson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div><div>I amend:</div><div><br></div><div>OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe crypto:hash_* functions.</div><div><br></div></div></blockquote><div><br></div>Thanks Sverker,</div><div><br></div><div>I like what you're saying, however that does not correspond to my experience. </div><div>I've been performing my tests using Erlang/OTP 21.1, but when I called</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; ">crypto:hash_final( {md5, <<<b>1</b>:92/unsigned-integer-unit:8>>} )</font></div></div></blockquote></div></div></blockquote></blockquote></div></blockquote><div><br></div>therefore, using a fake hash_state() value which tend to cause VM to bail out reporting a segmentation fault.</div><div><br></div><div>Could you please run the line above on one of your run-times (VM) and confirm your assertion.</div><div><br></div><div>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.</div><div><br></div><div>Kind regards</div><div><br></div><div>V/</div><div><br></div><div><div><br></div><br><blockquote type="cite"><div><div>On mån, 2019-04-15 at 15:45 +0200, Sverker Eriksson wrote:</div><blockquote type="cite"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>/Sverker, Erlang/OTP</div><div><br></div><div>On mån, 2019-04-15 at 12:03 +0200, Valentin Micic wrote:</div><blockquote type="cite">Hmmm… I may need to restate the question:<div><br></div><div>Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions?</div><div><br></div><div>Thanks in advance.</div><div><br></div><div>V/</div><div><br></div><div><div><div>On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi, </div><div><br></div><div>I've been investigating a feasibility of saving of <font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; "><i>hash_state() -- </i></font>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.</div><div>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 <i>fake</i> values for <font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; "><i>hash_state() </i></font> are given.</div><div><br></div><div>The results are interesting.</div></div><div><br></div><div>A call to, say, <font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; ">erlang:md5_final( <<0:<b>88</b>/unsigned_integer-unit:8>> )</font> (*), or </div><div> <font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; ">erlang:md5_final( <<1212312312:<b>88</b>/unsigned_integer-unit:8>> )</font>, or, indeed</div><div><font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; ">crypto:hash_final( {md5, <<0:<b>92</b>/unsigned-integer-unit:8>>} )</font></div><div><br></div><div>will all produce:</div><div><br></div><div style="font-size: 13px; "><font class="Apple-style-span" face="'Courier New'"><<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>></font></div><div><br></div><div>Presumably this may be due to some default value that has been used for all invalid values for <i><font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; ">hash_sate()</font>.</i></div><div><br></div><div>However, a call using a <i>fake</i> (yet "non-zero") value in <font class="Apple-style-span" face="'Courier New'" style="font-size: 13px; ">crypto:hash_final( {md5, <<<b>1</b>:92/unsigned-integer-unit:8>>} )</font> results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?).</div><div><br></div><div>As it appears that some internal tests are performed in order to verify the <i style="font-size: 13px; "><font class="Apple-style-span" face="'Courier New'">hash_state()</font></i> value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty?</div><div><br></div><div>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?</div><div><br></div><div>Kind regards</div><div><br></div><div>V/</div><div><br></div><div>(*) <b>88</b> corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, <b>92</b> is a number of octets in md5 hash_state() equivalent used by crypto library.</div><div><br></div></div>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br></div><pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre></blockquote><pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre></blockquote></div>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></body></html>