hash_state() and Segmentation Fault

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

hash_state() and Segmentation Fault

Valentin Micic-6
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Valentin Micic-6
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Hans Nilsson R (AL/EAB)
The hash_state() is just an Erlang reference.  It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib.

The area is allocated by enif_alloc_resource  (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page)

Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html  section "Resource objects".

/Hans

On 4/15/19 12:03 PM, 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Sverker Eriksson-5
In reply to this post by Valentin Micic-6
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Sverker Eriksson-5
I amend:

OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe crypto:hash_* functions.


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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Valentin Micic-6

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Valentin Micic-6
In reply to this post by Hans Nilsson R (AL/EAB)
Thanks Hans,

For some reason, I've been under impression that newer versions of Erlang/OTP (19.x and higher) no longer have a dependency on (third party) OpenSSL library.
Was I wrong to think that?

Kind regards

V/

On 15 Apr 2019, at 2:54 PM, Hans Nilsson R wrote:

> The hash_state() is just an Erlang reference.  It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib.
>
> The area is allocated by enif_alloc_resource  (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page)
>
> Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html  section "Resource objects".
>
> /Hans
>
> On 4/15/19 12:03 PM, 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
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Sverker Eriksson-5
In reply to this post by Valentin Micic-6
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Valentin Micic-6
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: hash_state() and Segmentation Fault

Hans Nilsson R (AL/EAB)
In reply to this post by Valentin Micic-6
OTP still depends on a third-party cryptolib, OpenSSL or LibreSSL. We have no plans on including a cryptolib into OTP.
/Hans

On 4/15/19 4:56 PM, Valentin Micic wrote:

> Thanks Hans,
>
> For some reason, I've been under impression that newer versions of Erlang/OTP (19.x and higher) no longer have a dependency on (third party) OpenSSL library.
> Was I wrong to think that?
>
> Kind regards
>
> V/
>
> On 15 Apr 2019, at 2:54 PM, Hans Nilsson R wrote:
>
>> The hash_state() is just an Erlang reference.  It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib.
>>
>> The area is allocated by enif_alloc_resource  (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page)
>>
>> Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html  section "Resource objects".
>>
>> /Hans
>>
>> On 4/15/19 12:03 PM, 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
>>>> [hidden email]
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

smime.p7s (5K) Download Attachment