search

vincenthz / hs-cryptohash

efficient and practical cryptohashing in haskell. DEPRECATED in favor of cryptonite
Other
30 stars 24 forks source link

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

Closed NerdGGuy closed 1 year ago

NerdGGuy commented 10 years ago

Any chance on accepting Byteable types for crypto operations?

vincenthz commented 10 years ago

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.

NerdGGuy commented 10 years ago

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?

vincenthz commented 10 years ago

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.

alexanderkjeldaas commented 9 years ago

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

vincenthz commented 9 years ago

an updated interface that can take any sort of byte array is now available in cryptonite.