Because if you read the article, you would have been informed that through WASM they did not have access to existing PRNG (e.g. /dev/urandom), and had to roll a mersenne twister. Which should not be used.

It is about implementation, not about WASM

Yes, that's my point. WASM is new. So why does it not just have strong cryptographic functions from the very beginning? Strong random generators are super important today. Why don't they just demand strong crypto functions in every implementation? I mean, this calls just for endless troubles, if you don't can trust a random generator in WASM (depending on the implementation).

WASM in the browsers doesn't seem to have the full force of support from the browser vendors.

How so? WASM is supported in every non-deprecated browser: https://caniuse.com/wasm

Also, this was an implementation bug, not a WASM bug. WASM specifies an execution environment; what developers do in it is entirely up to them (and the vendors of the libraries they use).

WASM is a "pure" VM/execution environment without any standard system calls or library functions. Given that, you'll need to provide your own seed and your own cryptographically-secure PRNG implementation.

Trust Wallet seems to have botched the latter [1] (in fact, it looks to me like they aren't even understanding the implications of that decision based on the PR description [2]). How is that WASMs fault?

[1] https://github.com/trustwallet/wallet-core/pull/2240

[2] They say that their choice of using the Mersenne Twister is "inspired by emscripten", which does no such thing.

This means that WASM is a garbage tool for this purpose and they should have gone a different route.

No, you seem to be misunderstanding what WASM is and isn't. WASM is the specification of a bytecode format (i.e. something like a virtual ISA) and the corresponding execution environment.

It's perfectly possible to implement a secure PRNG in WASM and supply entropy/a seed as a parameter to that, and this is exactly what emscripten does. Trust just happened to provide a non-secure PRNG in their implementation (and ironically quotes emscripten's PR while doing the opposite).

They reimplemented low-level crypto primitives in an insecure way, and quite possibly without even realizing that they were doing so, and their users are paying the price. No language or framework can protect developers from that.

That sounds incorrect, though WASM you have access to webcrypto getrandombytes which is native OS randomness.

Yes, but that wasn't even the problem.

Trust Wallet needlessly wrapped `std::random_device` (which might or might not be cryptographically secure by itself, depending on how it's implemented in whatever WASM-generating stack they use) in an instance of `std::mt19937` (which is definitely insecure, whether seeded cryptographically or not, due to being seeded with only 32 bits of entropy in their implementation; but even seeded properly, a Mersenne Twister would eventually leak internal state).

Couldn't they have used CryptMT [0] instead of MT19937 (or whatever mersenne twister implementation they had)? Saying mersenne twister should not be used is a bit misleading as it all depends on the specific implementations and needs of the application.

Anyhow, they could still have used webcrypto through WASM or even through JavaScript (as they can send the data back). This is really not a problem with WASM but moreso with the stupid implementation of this wallet.

edit: According to this PR they were indeed using std::mt19937 [1]. In fact I would go further ahead and say this is a general issue of C++ itself which just does not provide good PRNGs in the stdlib at all, with multiple way of achieving different (but similarly broken) PRNG results.

[0]: https://en.m.wikipedia.org/wiki/CryptMT

[1]: https://github.com/trustwallet/wallet-core/pull/2240

Ironically, they probably even did that (depending on their implementation of std::random_device).

The problem is what they did with that random seed once they had retrieved it (i.e. seed a non-cryptographic Mersenne Twister with only 32 bits of it).