Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


hmac :: (Byteable a, Byteable b, HashAlgorithm c) => a -> b -> HMAC c #19

NerdGGuy opened this Issue · 4 comments

3 participants


Any chance on accepting Byteable types for crypto operations?


yes, I think this is a change that make sense.

More generally moving all the hashing operation to Byteable so that they can operate on SecureMem object too would be the general direction I think. The only worrying thing is the compatibility with previous versions.


Securemem, agree, but securemem crypto would be longer term goal and would be in c? tobytes makes a nonsecure copy right?

A bytesting is already byteable. And byteable is already a dependency. Backwards compatibility shouldn't be an issue?


No, it wouldn't in this case thanks to the withBytePtr "backdoor" method.

For the compatibility, my only worry is that making thing more polymorphic would trigger errors when it's the only thing that give the ability to pinpoint the actual type for ghc. It's pretty remote for a well-formed libraries/programs I suppose, but a worry nonetheless.


I noticed this as well (added a specific issue for the SecureMem before I read this one)

I've filed issues with other libraries that they should use SecureMem. Having this facility in a lower level library is needed IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.