Earlier today I noticed an old open issue for keyed Blake2 support (see #196). Since I need Blake2b-MAC for one of my own pet projects, and it was a simple matter of properly exposing an existing C interface, I figured I'd have a go at adding it myself.
Here's a summary of the changes:
Expose keyed init functions for all Blake2 variants (as suggested in a comment from @vincenthz on #196)
Add HashBlake2 typeclass in Crypto.Hash.Blake2 to support keyed initialisation.
Add a KeyedBlake2 module to Crypto.MAC with an interface that's essentially isomorphic to the other modules in Crypto.MAC
Add tests for all variants. I used the same methodology as the tests for KMAC that were already in the test suite. I got my test vectors from https://github.com/BLAKE2/BLAKE2/.
Note that this is my first time messing around with cryptonite internals, and my experience with the foreign function interface is also pretty limited. In particular, I'd really appreciate a sanity check on the following points:
Organisation of the new API.
The function signatures for the various cryptonite_blake2XYZ_init_key entry points in the C layer.
My implementation of initialize in Crypto.MAC.KeyedBlake2 (the only nontrivial piece of unsafe code)
If there's anything else I need to address, please don't hesitate to tell me.
Earlier today I noticed an old open issue for keyed Blake2 support (see #196). Since I need Blake2b-MAC for one of my own pet projects, and it was a simple matter of properly exposing an existing C interface, I figured I'd have a go at adding it myself.
Here's a summary of the changes:
Note that this is my first time messing around with
cryptonite
internals, and my experience with the foreign function interface is also pretty limited. In particular, I'd really appreciate a sanity check on the following points:cryptonite_blake2XYZ_init_key
entry points in the C layer.initialize
inCrypto.MAC.KeyedBlake2
(the only nontrivial piece of unsafe code)If there's anything else I need to address, please don't hesitate to tell me.
Thanks a lot!