"On Libbitcoin Explorer 3.x versions, bx seed uses the Mersenne Twister pseudorandom number generator (PRNG) initialized with 32 bits of system time."<p>That's a hell of an amateur mistake to make. 50/50 odds whether it was incompetence or deliberate fraud. Maybe 80/20; that flaw is so simple anyone can attack it. Which apparently is happening right now. It's much better if your crypto library generates keys only you can hack.
Note: "Libbitcoin" here is a company name, and not a name of the core bitcoin library.<p>Only their products and whoever used them as a 3rd party is affected.
Reminds me of attacks people were running on 'brainwallets' a while back - i.e. wallets whose initial key material was just a passphrase you'd remember. The idea was that you could keep the passphrase stored <i>nowhere</i> and not have to worry about it being stolen by... well, any of the 10,000 things out there looking for cryptocurrency keys. Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly, and once people realized that these wallets were crackable, they all got drained pretty quick.<p>Owning Bitcoin is like paying into an involuntary bug bounty program. Every time someone finds a bug, your life savings get wiped out.
Worth noting: libbitcoin is an obscure project with an impressive name.<p>In that it's not used by bitcoind or any wallets I know of: it's mainly of interest here because the book Mastering Bitcoin used it for examples.
> <a href="https://blog.ledger.com/Funds-of-every-wallet-created-with-the-Trust-Wallet-browser-extension-could-have-been-stolen/" rel="nofollow noreferrer">https://blog.ledger.com/Funds-of-every-wallet-created-with-t...</a><p>This "Milk Sad" was apparently discovered by the guys at Ledger (they make a hardware wallet but which can also be used as a U2F device for, say, SSH logins).<p>These guys are good. Their CTO (or ex-CTO ?) was part of the original FIDO alliance that came up with the U2F spec.
The spiciest bit:<p>> During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation.<p>> We do not agree with this assessment.<p><a href="https://milksad.info/disclosure.html#libbitcoin-vendor-response" rel="nofollow noreferrer">https://milksad.info/disclosure.html#libbitcoin-vendor-respo...</a>
Seems a bit overkill with a brand + domain name for every new vulnerability.<p>Don't get me wrong, it's a nice find and all, but I'm really distracted by all the fluff.
Was the code seeding by seconds since epoch, or nanoseconds since epoch truncated to 32 bits? Broken either way.<p><a href="https://github.com/libbitcoin/libbitcoin-system/blob/a1b777fc51d9c04e0c7a1dec5cc746b82a6afe64/src/crypto/pseudo_random.cpp#L70">https://github.com/libbitcoin/libbitcoin-system/blob/a1b777f...</a><p><pre><code> const auto now = high_resolution_clock::now();
return static_cast<uint32_t>(now.time_since_epoch().count());</code></pre>
Some extra relevant links:<p><a href="https://github.com/libbitcoin/libbitcoin-system/pull/559">https://github.com/libbitcoin/libbitcoin-system/pull/559</a><p>The pull request adding the vulnerability, the lack of review or collaboration is worth noticing. The prior code was already dubious in that AFAIK std::random_device library doesn't promise that the randomness is suitable for cryptography. I believe on common systems where this code was run the old code was not <i>likely</i> to be exploitable, but I wouldn't bet my money on it.<p><a href="https://twitter.com/evoskuil/status/1688657656620167169" rel="nofollow noreferrer">https://twitter.com/evoskuil/status/1688657656620167169</a><p>Developer commentary on this issue. I can't figure out what "long-documented intended usage" a seed command that mandates 128-bits of output but never has more than 32-bits of entropy would have.<p><a href="https://archive.is/A7Jn6" rel="nofollow noreferrer">https://archive.is/A7Jn6</a><p>The documentation the tweet references. I don't know how the 'Pseudorandom seeding' warning there would be distinguishable from warnings against CSPRNGs in favor of dice rolls or whatever, perhaps this is an example of the harm that chicken-little crying about CSPRNGS causes. Nor can I figure out for whose convenience this function would serve except attackers. In any case, this is the only place I found any kind of warning and the warning postdates the mastering bitcoin usage (as well as the change that made the command unconditionally unsafe).<p><a href="https://archive.is/HDe8h" rel="nofollow noreferrer">https://archive.is/HDe8h</a><p>Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys.<p><a href="https://archive.is/fhm5J#selection-12915.2-12915.10" rel="nofollow noreferrer">https://archive.is/fhm5J#selection-12915.2-12915.10</a><p>Current libbitcoin-explorer instructions telling users to use the seed command to generate BIP39 seeds (also private keys).<p><a href="https://archive.is/PWLKJ" rel="nofollow noreferrer">https://archive.is/PWLKJ</a><p>Current libbitcoin-explorer documentation on randomness noting that bx seed is the ONLY source of randomness available to users in the package, and that all other commands that need randomness require the user to provide it. It also notes that 'bx seed' will not function if less than 128-bits are requested.<p>The private key and bip39 seed usage (above) sure appears to be the "intended usage" in their documentation, but the "bx seed" function as currently implemented (since 2016) is unambiguously not fit for those purpose.
lol just straight up not using a cryptographically secure source of randomness. that's literally the first thing you do when you want secure cryptography. idiots
Are any of the following two things true:<p>Multi signature addresses mitigate this attack vector?<p>With the “taproot+schnoor” upgrade last year, it is impossible to tell if funds are stored in a single signature vs multi signature address?