vincenthz
hmac :: (Byteable a, Byteable b, HashAlgorithm c) => a -> b -> HMAC c
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. https://bitbucket.org/ssaasen/haskell-jwt/issue/7/consider-using-securemem
