WASM/no_std support about password-hashes

[newpavlov]

We have released scrypt v0.3 with no_std support, also we now test that all crates can be built on WASM. So I think we can close this issue.

[newpavlov]

scrypt depends on std, which causes issues in your case. It can be solved by migrating it to alloc, which will require bumping MSRV and thus releasing v0.3.0.

[slightknack]

I'm not sure if this is just a simple misconfig-uration on my part, but I'm not able to get scrypt running on wasm32-unknown-unknown. According to this issue for the rand crate, the "wasm-bindgen" feature should be flagged for WASM compilation.

However, from past experience, rand hasn't been the most reliable for WASM for me. The getrandom crate supports WASM reliably; I wonder if it might be a good idea to switch to it. Here's my code:

# Cargo.toml

# ... snip ...

scrypt = "0.3"

// lib.rs
extern crate scrypt;
use scrypt::{ScryptParams, scrypt_check, scrypt_simple};

// ... snip ...

// in some function:
let params = ScryptParams::new(15, 8, 1).unwrap();
let password = "some password";
let hash = scrypt_simple(password, &params).expect("Rng failed");

Compiled with:

$ cargo build --lib --release --target wasm32-unknown-unknown

When run, the script reports that the Rng failed. I'm not exactly sure where this error occurs - I think it might be while filling the salt with random values in scrypt_simple. I'm going to try rewriting my own scrypt_simple that doesn't depend on the same Rng and see if an error is still thrown.

[newpavlov]

Have you tried to add this line to your Cargo.toml?

getrandom = { version = "0.1", features = ["wasm-bindgen"] }

AFAIK rand does not have any WASM-incompatible parts, so issue is usually that the getrandom feature does not get enabled.