Implement feedable hmac

[reynir]

Analogous to ctx and feed_* but for computing hmacs incrementally. For when hmaci_* is not suitable. Fixes #154.

I'm open for suggestions in naming. The type hmac could be hmac_ctx for example, and the functions could be feed_hmac_bytes instead of hmac_feed_bytes.

[reynir]

I struggled a bit with the tests as k Digestif.t is opaque and we don't have the type equality k Digestif.t = k :(

[dinosaure]

Do you have a reason to define type hmac and not to use type ctx?

[reynir]

Yes. type hmac = ctx * string where the string is the "outer" part of the key. We could as well use ctx, but then:

• both hmac_init and hmac_get would take the key whereas with this design only hmac_init takes the key => room for mixing up keys at init and get.
• you might call get on a hmac ctx which results in the wrong hmac
• you might call init instead of hmac_init or you might use empty and compute a "hmac" with that and finally call hmac_get ~key ctx to get a (wrong) hmac.

Another possible solution is to define a type 'a ctx' and use a phantom type to keep track of whether we're computing a hmac (where we must do some extra initial and final steps) or a digest.

[dinosaure]

Another possible solution is to define a type 'a ctx' and use a phantom type to keep track of whether we're computing a hmac (where we must do some extra initial and final steps) or a digest.

Yes but it will breaks the API. I'm ok with the initial change. I will merge that when I have a time 👍.