libsodium-bindings icon indicating copy to clipboard operation
libsodium-bindings copied to clipboard

Published 20 hours ago • verified publisher icon haskell-cryptography

Pure cryptographic functions in `sel`

Open intricate opened this issue 8 months ago • 6 comments

I wanted to get some opinions on this.

Might it not be safe to define a few of the cryptographic functions in sel as pure (using unsafeDupablePerformIO)?

Some examples:

  • Sel.Hashing.hashByteString
  • Sel.Hashing.SHA256.hashByteString
  • Sel.Hashing.SHA512.hashByteString
  • Sel.Hashing.Short.hashByteString
  • Sel.Hashing.Password.hashByteStringWithParams
  • Sel.HMAC.SHA256.authenticate
  • Sel.HMAC.SHA512.authenticate
  • Sel.HMAC.SHA512_256.authenticate
  • Sel.SecretKey.Authentication.authenticate
  • Sel.PublicKey.Signature.signMessage

intricate avatar Mar 27 '25 14:03 intricate

@kozross Do you see any potential risk with doing so?

Kleidukos avatar Apr 08 '25 11:04 Kleidukos

@intricate if their libsodium implementations are not secretly stateful, then you have my go-ahead.

Kleidukos avatar Apr 09 '25 15:04 Kleidukos

I'll check them out, thanks.

intricate avatar Apr 09 '25 15:04 intricate

@intricate Do you still want to proceed? I'd like to release a new major version after this change of API. :) If you cannot, I'd be happy to take on that work.

Kleidukos avatar May 15 '25 06:05 Kleidukos

Hey @Kleidukos. I can likely get it done this weekend

intricate avatar May 15 '25 12:05 intricate

@intricate fantastic, don't hesitate to ask if you have any question or face any trouble. :)

Kleidukos avatar May 15 '25 12:05 Kleidukos

Can you document in the haddocks why some functions are "pure" and others aren't?

turion avatar Oct 10 '25 13:10 turion

@turion: were there any particular examples that you were looking at?

In Sel.PublicKey.Signature.signMessage, for example, I left some haddock there explaining why that function is impure. I'd be happy to PR docs for any other functions where you think the reason for impurity is unclear.

intricate avatar Oct 10 '25 18:10 intricate

See for example decrypt which uses unsafeDupablePerformIO, while encrypt doesn't. I don't understand why one of them is treated that way and not the other.

turion avatar Oct 12 '25 16:10 turion

I see what you mean about it not being very clear.

encrypt is impure because it also generates a random nonce for the crypto_box operation (I'm guessing this is done in an effort to prevent nonce misuse). So perhaps that should be documented.

It could also be nice to offer a pure variant of encrypt which allows the caller to specify a nonce (documented with a warning about misuse).

intricate avatar Oct 13 '25 02:10 intricate