Macro hdk::prelude::secure_primitive

macro_rules! secure_primitive {
    ($t:ty, $len:expr) => { ... };
}

Cryptographic secrets are fiddly at the best of times.

In wasm it is somewhat impossible to have true secrets because wasm memory is not secure.

• The host can always read wasm memory so any vulnerability in the host compromises the guest.
• The host/rust generally doesn’t guarantee to immediately wipe/zero out freed memory, either when a zome call is running or after a wasm instance is thrown away.

Most of the time we should just try to minimise the interaction between wasm and secret data.

For example, lair keeps all our private keys internal and we can only send it signing requests associated with public keys.

In other contexts it is more difficult, such as when generating secrets from raw cryptographic random bytes and sending them to peers directly.

The best we can do here is try to protect ourselves against third parties across the network. e.g. We don’t want other machines to simply remote_call a successful timing attack.

MITM attacks are mitigated by the networking implementation itself.

@todo given how impossible it is for wasm to protect its memory from the host, it would make more sense to:

• use key exchange protocols like libsodium kx https://libsodium.gitbook.io/doc/key_exchange.
• keep secrets inside lair with all algorithms behind an API, wasm only has access to opaque references to the secret data.

@todo implement explicit zeroing, moving and copying of memory for sensitive data. - e.g. the secrecy crate https://crates.io/crates/secrecy