Rather than creating a set of <<0,…,0>> every time and then throwing it away,
we now reuse a constant. They are small enough they are still small-binaries, but a
process can keep them around and use them whenever it needs to go to the
low-level area.
* Introduce enacl:verify/0 to verify the integrity of the library.
* Always run keypair functions on the dirty schedulers.
* Do not call NIFs when creating zerobytes. Avoid constructing new binary data, but reuse a constant.
* The box/box_open and box_seal/box_seal_open API is so expensive to call there is little overhead in
running it on the DS always.
* Call the functions `box_seal` and `box_seal_open` to match the libsodium names in module `enacl`.
* Fix a bug in the C NIF: We should fail if the input is `<` SEALBYTES but not on `<=` SEALBYTES. The latter made it impossible to encode empty messages.
* Add variants which run directly on the interpreter scheduler for small messages.
Also:
* Provide full EQC functions for the testing purposes. This generated around 13000 random test cases in a 5 minute run, all passing.# Please enter the commit message for your changes. Lines starting
Provide non-dirty-scheduler variants for small strings, accurately bump
reductions for these strings.
While here, provide EQC test cases for the two functions.
Go over the README file, and improve its contents. Add a Usage/hints section
with some helpful hints on how to use the library in turn. Also while here, make
sure that `rebar doc` works as expected and fix every documentation bug in
the EDoc sections, so it compiles and works. Verify the documentation output
is nice-looking while at it.
This patch implements beforenm/afternm calls from NaCl for `box` style
crypto. It's main advantage is way faster computations, since it avoids
recomputing in the elliptic curve for every message.
While here, bump the version to v0.11.0 as new functionality was added.
When calling `stream_xor/3` it is possible to supply `iodata()` directly
and you don't have to convert to a binary first. Reflect this in the type
of the specification.
* Generalize binary generation because it is used again and again.
* Use generalized binary generation in the hash functions since they are much faster as generators.
To avoid the common mistake of re-arranging keypairs, provide them in a map which
forces the programmer to unpack the map in order to obtain the keys. This in turn makes
it harder to swap the PK/SK pair around and mistakenly giving out the secret key to the world.
This is not like the `crypto` subsystem, where a runner is needed to keep the
crypto system up and running. Rather, we can run without an application runner.
