BLAKE3

[Jesper Louis Andersen]

If you can accept BLAKE2b, the github.com/jlouis/enacl library supports
that through the generichash set of functions (from libsodium). It provides
many of the BLAKE-3 benefits, while also providing a large set of other
useful primitives on top.

If you really require BLAKE-3 support, rolling a NIF with it should be
fairly straightforward. You can eventually take a look at the C code in
enacl, which roughly can be adapted into the style of the BLAKE-3 C calls.
Hide the BLAKE-3 state in a NIF resource and protect its access by a mutex.

However, I think their impressive benchmarks are obtained by using a
parallelized BLAKE-3 against a serial BLAKE2b. In an Erlang setting, it
would probably be detrimental to the overall health of the system to grab
all CPU cores for hash computations in the name of speed, provided you have
enough work to do for the other cores. Your hash computation will be fast,
but everything else would just incur higher latency. This might not be
desirable.

As for the security margin, what do you have in mind? Both generichash and
BLAKE-3 supports a keyed hashing variant, and I would definitely recommend
using those if possible. But in practice, SHA-2 isn't really "insecure" as
far as what we are trying to use it for (except for length-extension, but
there are ways around that). In short, what do you have in mind w.r.t "more
security?"

On Fri, Apr 17, 2020 at 10:08 PM - Neustradamus - <neustradamus@REDACTED>
wrote:

> Hello Erlang community,
>
> For more security, can you add BLAKE3 support?
> - https://github.com/BLAKE3-team
> - https://github.com/BLAKE3-team/BLAKE3
> - https://github.com/BLAKE3-team/BLAKE3-specs
>
> Thanks in advance.
>
> Regards,
>
> Neustradamus



-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200418/237dce81/attachment.htm>