Comment by Taek

> CryptoJS / Ill Bloom (2026)

This is the one I'm referring to, it used some very dumb `Math.random()`-with-unverified-incantations code that should have been obvious if anyone had just looked at it. This one is responsible for the majority of hackable bitcoin addresses. It's really embarrassing that this kept going until 2020.

(At one point this would have been a tricky situation, though, because around 2009-2013 when bitcoin wallets were first being generated in web browsers, Internet Explorer didn't provide a CSPRNG API. Because of the prevalence of IE, an in-javascript CSPRNG would have been justified as a fallback if it had proper cryptographic mixing of mouse input entropy and perhaps timing execution jitter entropy as well, along with good entropy estimation to decide when enough seeding has been performed to start generating keys. Some wallet websites actually did mouse entropy collection at the time (e.g. https://www.bitaddress.org), but often with dubious mixing. Might have been best to just ban Internet Explorer.)

> Libbitcoin / Milk Sad (2023)

Mersenne twister... likewise should have been identified as not even remotely correct. Not a serious CSPRNG at all. Similar to the CryptoJS case.

> Trust Wallet Browser Extension (2023)

Also Mersenne twister, similar to the CryptoJS case.

> Trust Wallet iOS / Trezor Library

Time-based seeding, with an exceptionally weak PRNG with only 32 bits of state. Similar to the CryptoJS case.

> Android SecureRandom (2013)

This is a buffer bug that caused existing seed data to be overwritten by newer data rather than correctly appending it. The serious cryptographic primitives weren't broken, just the input. But it is genuinely scary. Unlike the other examples, it wasn't immediately identifiable because it gave the appearance that a CSPRNG was being implemented, and being a platform API it is just as scary as the Debian bug in 2008.