Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Open
NerdGGuy opened this Issue · 4 comments

3 participants

@NerdGGuy

Any chance on accepting Byteable types for crypto operations?

@vincenthz
Owner

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

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
Owner

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

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

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.