4 ms·

The flaw here was in a dependency introduced by targeting WASM, and could apply to any project of any kind relying on random number generation for a cryptograph

The flaw here was in a dependency introduced by targeting WASM, and could apply to any project of any kind relying on random number generation for a cryptographic purpose. It is not a "crypto-currency" specific problem.

snapcaster 3y ago
It sort of is because cryptocurrency inherently makes the stakes so high (all your money). Currently software development is more an art than a science, and even very competent people make mistakes or have unforeseen problems/behavior in their programs
veeti 3y ago
The flaw was not in a dependency but Trust Wallet's first party code [1]. They decided that Mersenne Twister would be sufficient for generating cryptographically random data and specifically called it "secure" [2]. Very unfortunate. [1] https://github.com/trustwallet/wallet-core/blob/3.1.0/wasm/src/Random.cpp https://github.com/trustwallet/wallet-core/blob/3.1.0/wasm/s... [2] https://github.com/trustwallet/wallet-core/pull/2240 https://github.com/trustwallet/wallet-core/pull/2240
- detrites 3y ago
  Yes, a terrible decision - but still a decision left up to any developer in a similar position - which, with the trend to WASMify things may well happen again in other projects, until it's better addressed at the source. Honestly, it's so bad it makes me wonder if a bad actor could have had influence over such a decision in this case. Reports of Trust Wallet accounts being randomly pilfered without some plausible other cause might go some way to figuring that out.
  - lxgr 3y ago
    This makes no sense. What source should it be addressed? This is an issue of standard libraries, whereas WASM is a specification of an execution environment. WASM doesn't have a standard library, since it doesn't even have a canonical source language! It's like demanding that x86 or aarch64 offer better Unicode or SVG support.
    - detrites 3y ago
      Developers should never end up in a situation where they feel the best cryptography solution is to "roll their own". That's likely what happened here. And the situation needs to change. It doesn't matter where in the stack that change is affected.
      - lxgr 3y ago
        So you're saying all languages (and in fact ISAs, because that really describes WASM more accurately!) need to come with a static analyzer that detects and prevents any attempts of implementing low-level cryptography rather than calling out to a high-quality library? Because that's what happened here. What we can do is provide well-tested and ergonomic high-level cryptographic libraries; I don't see how we can enforce their use.
        detrites 3y ago
        Well if you know of a simple way to target - reliably - a high-quality crypto lib that can access any underlying OS entropy source to generate a decently random number, with WASM, please inform us of it here; it'd be great to know. Though admittedly, it seemed terrible if there wasn't, so I would be happy if the post can be proven deficient. I'd have ordinarily assumed many options available in the .js ecosystem, instead accepting it's a WASM OS-access issue.
jakelazaroff 3y ago
You don't think that your bank would get your money back if this happened to them?
- detrites 3y ago
  Which bank? SVB? FRB? You raise an important point though: crypto is not for the faint-hearted. "Be your own bank" has exactly that much responsibility attached. Many don't fully appreciate that.
  - mrguyorama 3y ago
    Find a depositor that lost money from either bank.
    - detrites 3y ago
      Sure, but major banks failing one after the other might not exactly promote confidence in ones bank deposits.
      - asadotzler 3y ago
        You're working really hard in this discussion. Why?
        detrites 3y ago
        Baha! What? It's a topic I'm interested in, like everything I comment on. I'm not sure how that's "working really hard". Interests I choose to engage in are a joy and relaxation. Is it not that way for you?

snapcaster 3y ago

It sort of is because cryptocurrency inherently makes the stakes so high (all your money). Currently software development is more an art than a science, and even very competent people make mistakes or have unforeseen problems/behavior in their programs

veeti 3y ago

The flaw was not in a dependency but Trust Wallet's first party code [1]. They decided that Mersenne Twister would be sufficient for generating cryptographically random data and specifically called it "secure" [2]. Very unfortunate. [1] https://github.com/trustwallet/wallet-core/blob/3.1.0/wasm/src/Random.cpp https://github.com/trustwallet/wallet-core/blob/3.1.0/wasm/s... [2] https://github.com/trustwallet/wallet-core/pull/2240 https://github.com/trustwallet/wallet-core/pull/2240

detrites 3y ago
Yes, a terrible decision - but still a decision left up to any developer in a similar position - which, with the trend to WASMify things may well happen again in other projects, until it's better addressed at the source. Honestly, it's so bad it makes me wonder if a bad actor could have had influence over such a decision in this case. Reports of Trust Wallet accounts being randomly pilfered without some plausible other cause might go some way to figuring that out.
- lxgr 3y ago
  This makes no sense. What source should it be addressed? This is an issue of standard libraries, whereas WASM is a specification of an execution environment. WASM doesn't have a standard library, since it doesn't even have a canonical source language! It's like demanding that x86 or aarch64 offer better Unicode or SVG support.
  - detrites 3y ago
    Developers should never end up in a situation where they feel the best cryptography solution is to "roll their own". That's likely what happened here. And the situation needs to change. It doesn't matter where in the stack that change is affected.
    - lxgr 3y ago
      So you're saying all languages (and in fact ISAs, because that really describes WASM more accurately!) need to come with a static analyzer that detects and prevents any attempts of implementing low-level cryptography rather than calling out to a high-quality library? Because that's what happened here. What we can do is provide well-tested and ergonomic high-level cryptographic libraries; I don't see how we can enforce their use.
      - detrites 3y ago
        Well if you know of a simple way to target - reliably - a high-quality crypto lib that can access any underlying OS entropy source to generate a decently random number, with WASM, please inform us of it here; it'd be great to know. Though admittedly, it seemed terrible if there wasn't, so I would be happy if the post can be proven deficient. I'd have ordinarily assumed many options available in the .js ecosystem, instead accepting it's a WASM OS-access issue.

jakelazaroff 3y ago

You don't think that your bank would get your money back if this happened to them?

detrites 3y ago
Which bank? SVB? FRB? You raise an important point though: crypto is not for the faint-hearted. "Be your own bank" has exactly that much responsibility attached. Many don't fully appreciate that.
- mrguyorama 3y ago
  Find a depositor that lost money from either bank.
  - detrites 3y ago
    Sure, but major banks failing one after the other might not exactly promote confidence in ones bank deposits.
    - asadotzler 3y ago
      You're working really hard in this discussion. Why?
      - detrites 3y ago
        Baha! What? It's a topic I'm interested in, like everything I comment on. I'm not sure how that's "working really hard". Interests I choose to engage in are a joy and relaxation. Is it not that way for you?