3 ms·

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 impor

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).

dboreham 3y ago
WASM in the browsers doesn't seem to have the full force of support from the browser vendors.
- lxgr 3y ago
  How so? WASM is supported in every non-deprecated browser: https://caniuse.com/wasm 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).
lxgr 3y ago
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 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.
- mrguyorama 3y ago
  This means that WASM is a garbage tool for this purpose and they should have gone a different route.
  - lxgr 3y ago
    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.

dboreham 3y ago

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

lxgr 3y ago
How so? WASM is supported in every non-deprecated browser: https://caniuse.com/wasm 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).

lxgr 3y ago

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 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.

mrguyorama 3y ago
This means that WASM is a garbage tool for this purpose and they should have gone a different route.
- lxgr 3y ago
  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.