Hacker News new | ask | show | jobs
by detrites 1140 days ago
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.
3 comments

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/s... [2] https://github.com/trustwallet/wallet-core/pull/2240

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.

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.

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

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.

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
You don't think that your bank would get your money back if this happened to them?
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.

Find a depositor that lost money from either bank.
Sure, but major banks failing one after the other might not exactly promote confidence in ones bank deposits.
You're working really hard in this discussion. Why?
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?