4 ms·

Why is in something so new (WASM), a such bad random generator?

deleted 3y ago
[deleted]
4gotunameagain 3y ago
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
- nailer 3y ago
  That sounds incorrect, though WASM you have access to webcrypto getrandombytes which is native OS randomness.
  - lxgr 3y ago
    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).
- _trampeltier 3y ago
  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.
- doodlesdev 3y ago
  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 ways of achieving different (but similarly broken) PRNG results. [0]: https://en.m.wikipedia.org/wiki/CryptMT https://en.m.wikipedia.org/wiki/CryptMT [1]: https://github.com/trustwallet/wallet-core/pull/2240 https://github.com/trustwallet/wallet-core/pull/2240
  - lxgr 3y ago
    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).

deleted 3y ago

[deleted]

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

nailer 3y ago
That sounds incorrect, though WASM you have access to webcrypto getrandombytes which is native OS randomness.
- lxgr 3y ago
  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).
_trampeltier 3y ago
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.
doodlesdev 3y ago
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 ways of achieving different (but similarly broken) PRNG results. [0]: https://en.m.wikipedia.org/wiki/CryptMT https://en.m.wikipedia.org/wiki/CryptMT [1]: https://github.com/trustwallet/wallet-core/pull/2240 https://github.com/trustwallet/wallet-core/pull/2240
- lxgr 3y ago
  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).