It seems that there are a number of features in Libsodium that can be useful in some situations, while posing additional risks to the unwary user, eg. keypair derivation from a known seed: #18
Additionally, the existing API in Saltine already includes some functions that should be regarded as dangerous (the Crypto.Saltine.Core.Stream undetectable malleability issue, and Crypto.Saltine.Core.ScalarMult which is really an advanced feature and public key derivation/key exchange should rather be exported as specific APIs using the functions from Libsodium so people don't feel the need to build their own from the primitives).
I've been working on my own fork on exposing all interesting parts of Libsodium in Crypto.Saltine.Unsafe.* modules and only leaving the safest and easiest functionality in Crypto.Saltine.Core.*, one addition being a high-level key exchange API which exports functions for the client and server to operate on an opaque SessionKeys type, using the correct key for sending+receiving under the hood. It's not directly pull-request-compatible due to breaking API changes but I think this would be a good approach to take towards version 1.0.0.0
It seems that there are a number of features in Libsodium that can be useful in some situations, while posing additional risks to the unwary user, eg. keypair derivation from a known seed: #18
Additionally, the existing API in Saltine already includes some functions that should be regarded as dangerous (the
Crypto.Saltine.Core.Stream
undetectable malleability issue, andCrypto.Saltine.Core.ScalarMult
which is really an advanced feature and public key derivation/key exchange should rather be exported as specific APIs using the functions from Libsodium so people don't feel the need to build their own from the primitives).I've been working on my own fork on exposing all interesting parts of Libsodium in
Crypto.Saltine.Unsafe.*
modules and only leaving the safest and easiest functionality inCrypto.Saltine.Core.*
, one addition being a high-level key exchange API which exports functions for the client and server to operate on an opaqueSessionKeys
type, using the correct key for sending+receiving under the hood. It's not directly pull-request-compatible due to breaking API changes but I think this would be a good approach to take towards version 1.0.0.0