You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are currently using libsodium (via sodiumoxide crate). I see a number of reasons against it:
libsodium is written in C and doesn't fully conform to Rust conventions. For example, we have to call init() (do we?), or some of its functions will not be thread-safe.
libsodium only provides a high-level API. We cannot use it to implement a VRF (New VRF implementation #1653), or randomness (Randomness NEPs#22), or anything else that requires low-level cryptography.
We only use a small subset of libsodium's functionality. When I searched through the code, I only found uses of SHA-256 hash function and Ed25519 signature scheme. Yet, we compile and link the entire library.
I propose to use these crates instead of sodiumoxide:
For SHA-256: sha2. Also, consider switching to a more modern hash function, such as BLAKE2.
I'm going to ensure every c/c++ dependency doesn't use too new instruction set (which cause some validator with old cpus report: illegal instructions). This is better done before examine them so I'll take this
We are currently using libsodium (via sodiumoxide crate). I see a number of reasons against it:
I propose to use these crates instead of sodiumoxide:
The text was updated successfully, but these errors were encountered: