Since the chacha20poly1305 constructions were the IETF variants,
we renamed those so they follow the official library better. While
here, we also fixed the argument order of the files.
The order of parameters were in the wrong order. Make them equal
to the official order of libsodium.
While here, rename NONCEBYTES to NPUBBYTES so it reflects the
underlying names as well.
If we, for some reason, fail to the error-path, then binaries allocated
are not being released properly back to the erlang runtime. Fix this
in the usual fashion by using a stack of undo-operations, and thread
them via goto.
sign and generichash failed to release their resources under failure.
This can lead to subtle memory leaks in the very unlikely event
we can't initialize.
At least according to:
https://libsodium.gitbook.io/doc/hashing/generic_hashing
We noticed crashes when it was not 16-byte aligned - probably is
architecture dependent. This makes the safe choice and always 64-byte
align it.
The API for pwhash_str returns a cstring in the output buffer. These
are null terminated. However, we return the full buffer as a binary
back to Erlang. This means that we have a buffer with 0'es in the end.
The tests take this buffer and passes it back in as is. Hence all the
tests pass. However, it is conceivable that if we write said buffer to
disk somewhere, we are not going to write those 0's out.
When we then load the ASCII-armored Argon2 string into memory again,
it is not 0-terminated as a cstring should be, and this produces
errors all over the place.
The fix is twofold:
* Return the full buffer to Erlang, but use binary:split/2 to create a
subbinary with the relevant part.
* Add a 0 in the end of ASCII Argon2 string before passing it to
libsodium
Since we are looking at pwhashing, and Argon2, we expect the
computational problem to be memory bound. Thus, spending a bit more
work in memory is not going to have any considerable impact on the
speed of this system.