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 :(

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

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.

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 👍.