120,000 Bitcoin Keys at Risk: Inside the Libbitcoin Vulnerability

OneKey recently disclosed a harrowing vulnerability. It may have exposed as many as 120,000 Bitcoin private keys. The fault lies not in hardware, not in users, but deeper—in a library called Libbitcoin Explorer (bx) 3.x.

That library used system time and a weak random generator: Mersenne Twister‑32, seeded only with a small 2³²‑bit seed space. As a result, private keys become predictable.

Crucially, this flaw affects third‑party wallets that rely on bx 3.x or Trust Wallet Core versions up to (but excluding) 3.1.1. That includes Trust Wallet Extension v0.0.172–v0.0.183 and Trust Wallet Core ≤ v3.1.1 (excluding v3.1.1 itself). It also spans any wallet—hardware or software—that integrated these libraries. However: this disclosed “Milk Sad” incident does not affect the mnemonic or private key security of OneKey’s hardware or software wallets.

Vulnerability Overview: Predictable Randomness

At its heart, the issue is simple: poor randomness. Libbitcoin Explorer (bx) 3.x generates “random” numbers using Mersenne Twister‑32, with a seed taken solely from the system time. The seed space is only 2³² possible values. That is small. It is brute‑forceable.

Because the seed is time‑based, an attacker with an approximate timestamp of when the key was generated can reconstruct the seed. With that seed, the attacker can replay the PRNG’s output, recreate the sequence, and deduce the private key.

In practice, a modern machine can enumerate all 2³² seeds within days. Once the attacker narrows the likely time window, they brute over the seed space, match the PRNG outputs, and steal the key. The system time dependency and the limited seed domain make this attack feasible.

Affected Scope: What Wallets Are at Risk?

Here’s the scope of affected software:

•  Trust Wallet Extension versions v0.0.172 through v0.0.183
•  Trust Wallet Core versions ≤ v3.1.1, excluding exactly v3.1.1
•  Any other wallets, hardware or software, that integrate Libbitcoin Explorer (bx) 3.x or Trust Wallet Core ≤ 3.1.1

If a wallet used those libraries, its key generation flow would be subject to this weakness. That said: the Milk Sad flaw disclosure explicitly states that OneKey wallets—hardware or software—do not suffer from this vulnerability.

• OneKey’s Claim: Why the Vulnerability Doesn’t Touch Them

OneKey offers both hardware and software wallets. They argue that their key generation and randomness sources are robust, independent, and resistant.

Hardware Wallets: True Randomness in Secure Elements

New‑generation OneKey hardware wallets use a Secure Element (SE) equipped with a True Random Number Generator (TRNG). No software seed, no system time, no external entropy seeding. The SE does everything internally.

This SE holds EAL6+ certification, meeting rigorous international cryptographic standards.

For legacy OneKey devices, the entropy comes from an internal TRNG in their ECU hardware. The output passes testing aligned with NIST SP800‑22 and FIPS‑140‑2 standards. The result: unpredictable, high‑quality randomness.

Thus, OneKey contends that its hardware wallets never rely on a 32‑bit time seed and never suffer the bx‑style flaw.

Software Wallets: System CSPRNGs, Not Mersenne Twister

OneKey’s Desktop & Browser Extension uses the Chromium WASM PRNG interface. That interface calls the operating system’s CSPRNG (cryptographically secure PRNG) as its entropy source. Modern OSes supply high‑quality randomness.

OneKey’s Mobile Wallet (Android / iOS) directly uses the system‑level CSPRNG APIs. These are designed and certified to be cryptographically secure.

So long as your OS, browser, and device hardware are intact, your entropy is strong. But OneKey warns: if your OS or device is compromised, the entropy source may be weakened.

They strongly recommend: use a hardware wallet for long‑term custody. Do not import mnemonics generated by software wallets into a hardware walle, it might inherit weak entropy.

OneKey’s security team has run entropy quality evaluations across all their platforms, following NIST SP800‑22 and FIPS‑140‑2. The results, they claim, fully meet the required cryptographic randomness standards.

Why This Tone Matters: Short, Active, Human Writing

You’ll notice in the disclosure and in this article that we favor active verbs, short sentences, present tense, and clarity. For instance: “The seed space is small.” “An attacker can reconstruct the seed.” “OneKey uses TRNGs.” We don’t over‑explain or bury the meaning in long, winding clauses.

When referencing data—like the “120,000 private keys”—we place it succinctly, in context. When naming affected versions, we list them in simple bullet form. That pattern helps readers grasp risk immediately, without wander.

What Happened, Step by Step

1. Libbitcoin Explorer 3.x uses Mersenne Twister‑32, seeded from system time.

2. That seed space is just 2³². Too small.

3. An attacker narrows the generation timestamp (e.g. “within these seconds”).

4. They brute‑force the 32‑bit seed space. Reconstruct the PRNG sequence.

5. From that, they derive the private key.

6. That private key lets the attacker control funds.

Thus, keys generated within that window become predictable—catastrophically.

What You Should Do

If you used Trust Wallet Extension v0.0.172–v0.0.183 or Trust Wallet Core ≤ 3.1.1 (excluding 3.1.1 itself), your keys may be vulnerable. Migrate your funds. Regenerate new keys using safe software or hardware. Transfer assets to fresh wallets whose entropy is sound.

For any wallet built on bx 3.x or vulnerable Trust Core, treat them as compromised.

Prefer hardware wallets whose entropy comes from a secure element and TRNG, not time‑seeded PRNGs.

Don’t import mnemonics from a software wallet into a hardware wallet unless you trust the entropy.

Keep your OS, browser, and device security strong. Even the best CSPRNG is worthless if the host is compromised.

This vulnerability is a sober lesson: entropy matters. You can write elegant wallet code, but if your randomness is flawed, the keys fall apart. The bx 3.x vulnerability doesn’t teach new mathematics—but it underscores old wisdom: never trust a predictable seed.

OneKey presents itself as safe in this scenario. Its hardware wallets avoid software entropy entirely. Its software wallets rely on vetted OS CSPRNGs. Its tests comply with NIST and FIPS standards. That said, the real-world safe path is: generate your funds in secure hardware, custody them in hardware, minimize reliance on software‑level randomness.

In short: the Milk Sad episode shakes trust in time‑seeded PRNGs. OneKey draws a hard line: its architecture avoids those pitfalls. Use caution. Move funds. Stay secure.

Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services.

Follow us on Twitter @themerklehash to stay updated with the latest Crypto, NFT, AI, Cybersecurity, and Metaverse news!