[erlang-questions] How to use crypto:hmac_init() and friends?

[Frans Schneider]

Dear list,

I have to create the HMAC of a message by including data at several
points in my code as shown below:

...
Mac_ctxt_init = crypto:hmac_init(sha256, Mac_key),
Mac_ctxt = case Version of
3 ->
Mac_ctxt1 = crypto:hmac_update(Mac_ctxt_init, Dhi_pub),
crypto:hmac_update(Mac_ctxt1, Dhir_pub);
2 ->
Mac_ctxt_init
end,
...
...
...
LMac_ctxt = crypto:hmac_update(Mac_ctxt, <<Version/binary,
Serialized/binary>>),
LMac = crypto:hmac_final_n(LMac_ctxt, 8),
...

This will always return <<>>! It already starts with the hmac_init()
which returns <<>>.

Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:2:2] [async-threads:10]
[hipe] [kernel-poll:false]

Eshell V7.1 (abort with ^G)
1> K =
<<9,138,157,154,221,37,75,104,28,207,127,232,193,207,68,39,22,88,62,219,15,114,22,236,68,226,141,39,69,212,143,123>>.
<<9,138,157,154,221,37,75,104,28,207,127,232,193,207,68,
39,22,88,62,219,15,114,22,236,68,226,141,39,69,...>>
2> crypto:hmac_init(sha256, K).
<<>>
3>

Using crypto:hmac(sha256, K, Data, 8) works fine, but is not usable.

Any idea what goes wrong or what I am doing wrong?

TIA,

Frans
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Sverker Eriksson]

Nothing is wrong (ugly maybe, but not wrong).

That empty binary is not really empty. It's a magic binary!
It's referring some internal emulator state (the hmac context in this case).

Just pass it along to hmac_update and hmac_final and you will get a nice
regular binary in the end.

The magic binary looks and behaves like an empty binary. It will even
lose its magic powers
and turn into a regular binary if serialized with term_to_binary.


/Sverker, Erlang/OTP

[Dmitry Belyaev]

Wouldn't it make sense to introduce a separate data type for these custom data? Or even allow to define new custom types in nifs or drivers with serialization and comparison rules.
--
Best wishes,
Dmitry Belyaev

On 20 November 2015 1:18:42 AM AEDT, Sverker Eriksson <sverker....@ericsson.com> wrote:

On 11/19/2015 02:37 PM, Frans Schneider wrote:

 Dear list,

 I have to create the HMAC of a message by including data at several 
 points in my code as shown below:

 ...
 Mac_ctxt_init = crypto:hmac_init(sha256, Mac_key),
 Mac_ctxt = case Version of
                3 ->
                    Mac_ctxt1 = crypto:hmac_update(Mac_ctxt_init, 
 Dhi_pub),
                    crypto:hmac_update(Mac_ctxt1, Dhir_pub);
                2 ->
                    Mac_ctxt_init
            end,
 ...
 ...
 ...
 LMac_ctxt = crypto:hmac_update(Mac_ctxt, <<Version/binary, 
 Serialized/binary>>),
 LMac = crypto:hmac_final_n(LMac_ctxt, 8),
 ...

 This will always return <<>>! It already starts with the hmac_init() <
 br />
which returns <<>>.

 Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:2:2] 
 [async-threads:10] [hipe] [kernel-poll:false]

 Eshell V7.1  (abort with ^G)
 1> K = 
 <<9,138,157,154,221,37,75,104,28,207,127,232,193,207,68,39,22,88,62,219,15,114,22,236,68,226,141,39,69,212,143,123>>.
 <<9,138,157,154,221,37,75,104,28,207,127,232,193,207,68,
   39,22,88,62,219,15,114,22,236,68,226,141,39,69,...>>
 2> crypto:hmac_init(sha256, K).
 <<>>
 3>

 Using crypto:hmac(sha256, K, Data, 8) works fine, but is not usable.

 Any idea what goes wrong or what I am doing wrong?

Nothing is wrong (ugly maybe, but not wrong).

That empty binary is not really empty. It's a magic binary!
It's referring some internal emulator state (the hmac context in this case).

Just pass it along to hmac_update and hmac_final and you will 
 get a
nice 
regular binary in the end.

The magic binary looks and behaves like an empty binary. It will even 
lose its magic powers
and turn into a regular binary if serialized with term_to_binary.


/Sverker, Erlang/OTP

[Frans Schneider]

Ok, thanks. It does work indeed.
But what do you mean with 'Ugly'"?

/Frans

[Sverker Eriksson]

On 11/19/2015 03:27 PM, Dmitry Belyaev wrote:

Wouldn't it make sense to introduce a separate data type for these custom data? Or even allow to define new custom types in nifs or drivers with serialization and comparison rules.
--

Yes, that would make sense.
Introducing a new data type in the language is quite a big operation though.

These empty magic binaries was sort of a last minute solution
to give NIF designers some way to return "safe pointers" to Erlang.


/Sverker, Erlang/OTP

[Sverker Eriksson]

That was self-criticism.
I was referring to the empty binary that's not really empty.

/Sverker, Erlang/OTP

[Viktor Söderqvist]

On 2015-11-19 16.00, Sverker Eriksson wrote:
> Introducing a new data type in the language is quite a big operation
> though.
>
> These empty magic binaries was sort of a last minute solution
> to give NIF designers some way to return "safe pointers" to Erlang.

Cool to learn that terms can have emulator state attached.

I think the magic could at least be documented. The documentation for
http://www.erlang.org/doc/man/crypto.html#hmac_init-2 just says the
context is a binary and doesn't mention anything about the emulator
state. That would be nice. I certainly would be confused if I ran into
this empty binary.

--
Viktor Söderqvist

[Jesper Louis Andersen]

On Fri, Nov 20, 2015 at 11:31 AM, Viktor Söderqvist <vik...@zuiderkwast.se> wrote:

I think the magic could at least be documented. The documentation for
http://www.erlang.org/doc/man/crypto.html#hmac_init-2 just says the
context is a binary and doesn't mention anything about the emulator
state. That would be nice. I certainly would be confused if I ran into
this empty binary.

It feels like a hack to me. Having an explicit opaque type for these kinds of things would be really nice.

--

J.