Portability and reliance on libsodium

[vuongDang]

• Feature Name: (Binder API)
• Start Date: (2021-12-07)

Summary

The current implementation of Stronghold is deeply integrated with libsodium.
Unfortunately sodiumoxide which is a port of libsodium on Rust has been deprecated which forces us to find a new solution
We propose a new runtime architecture in which memory management can have different implementations depending on the target platform.

Motivation

Libsodium is deeply rooted in the current implementation since we directly use the sodiumoxide crate in our code.
While it is really practical it also means that we force our users to rely on libsodium.
The main drawback is that we cannot support any platform which is also not supported by libsodium.
Hence it's really difficult for a potential contributor to add support for an alternative to libsodium.

Explanation

The goal is to provide, to the Stronghold runtime, some low level functions to manage the memory.
Currently this part is done by calling sodiumoxide directly.
We propose an API containing these low-level functions which implementation will depend on the target platform.
We call this API the Binder.
Functions of the Binder are totally taken from libsodium and libc and are:

• malloc()
• free()
• init
• mlock
• munlock
• mprotect()
• memzero()
• randombytes()
• memcmp()

At first these functions implementations will either be direct calls to libsodium or code taken from libsodium.
However with this architecture we will be easily be able to add code for platforms we currently don't support.
The implementation chosen will be decided with compilation flags.

Drawbacks

• We need to refactor the runtime code
• Adding an additional layer may impact performance
• by removing sodiumoxide we need to ship libsodium C lib or add it to the installation step

Rationale

• more portability we only need to implement the Binder interface to provide support for a new platform
• less dependency on libsodium, we can more easily add new ideas, for example from MemGuard

Discussions

• How do we replace sodiumoxide? 3 options:

  • Replace sodiumoxide and do Rust binding for libsodium
  • Call directly the libsodium C library with FFI
  • Copy libsodium code and modify it to our taste

  Currently the last option seems the more attractive since it would allow us to improve on libsodium by adding ideas from MemGuard.
  The downside is that we will need to support OS updates ourselves.

Future possibilities

This RFC is the first step towards having a HAL for Stronghold.
In the future adding support for new platforms will solely be located in the Binder part of the runtime.

[iota-for-flutter]

Are there any updates or future plans regarding how you intend to address this issue?

It seems that the problem lies more with the dependency on libsodium-sys being deprecated rather than libsodium itself. Currently (June 2023), I am encountering two problems when attempting to cross-compile Stronghold (and consequently libsodium-sys) for Android and iOS Simulator.

Download libsodium-sys and do the following:
1.) iOS: cargo build --target aarch64-apple-ios-sim => ERROR
2.) Android (using Android NDK v25): cargo ndk -t arm64-v8a build => ERROR

1.) The iOS Simulator problem could be easily solved when the build.rs in libsodium-sys is extended after line 189:

            "aarch64-apple-ios-sim" => {
                cflags += " -arch arm64";
                cflags += &format!(" -isysroot {}", sdk_dir_simulator);
                cflags += &format!(" -mios-simulator-version-min={}", ios_simulator_version_min);
                cflags += " -fembed-bitcode";
                host_arg = "--host=arm-apple-darwin10".to_string();
            }

2.) Android: I have no idea why this fails. I can manually create libsodium library BUT NOT via libsodium-sys.

COULDN'T YOU FORK THE LIBSODIUM-SYS REPO AND MAINTAIN THE WRAPPER LIBRARY?