Topic: If you used "bx seed" you probably already lost your bitcoins, but if... (Read 571 times)

nonono, the randomness only decreases if you say "Alan Turing" into a mirror 3 times with a hand covering one eye (hence summoning the actual eye of providence to the ceremony) and holding the dice you will use in the other

(accept my apologies, i agree that only good jokes belong on the Dev & Tech sub )

And why not mention dice or any other alternative?  Will their randomness be decreased if you speak their name? lol.

I doubt there is any rationalizing of this... no more clarity is going to be forthcoming.

i must be blind, of course it does (maybe I ignored everything after the boost:: ns, I have an aversion to boost)


hmmmm...


it's definitely hard to follow this kind of reasoning: because we should all be using dice rolls to seed the RNG, let's make an oblique error message in an obscure part of the repo, to guard against a default operating mode that's catastrophic to users (who apparently received recommendations from Bitcoin Jesus II: The Revenge in "Mastering Bitcoin", an ironic title as it turns out). would an above-average reader of that book even understand the warning message?

why not simply remove ANY insecure mode whatsoever, seeing as the developer was so security conscious? it seems the answer is "demos"

I fail to comprehend the reasoning of the authors of such a swiss-army-knife tool to cripple seeding and randomness and thus emit hackable entropy without explicitly throwing out big warnings on every use of bx seed and still promoting use cases at prominent spots like "Mastering Bitcoin". This is insanely irresponsible in my opinion to an extend that I'd call it malicious, this also fueled by the responses and denial of "a problem".

I can't see strong valid arguments to solely blame the users of bx seed and who knows which subcommand of bx which needs entropy or good randomness has severe issues, too.

This is far far from good.

I don't use github anymore but someone pinged me there, I loaded it-- only to see voskuil shitting on me: https://github.com/libbitcoin/libbitcoin-explorer/issues/728#issuecomment-1677195708  yet another reason to not use that site!

That kind of toxic deflection from his own errors using maliciously false personal attacks is exactly why development there gets zero review, and is probably the most direct causative reason for the vulnerability in the first place. Regardless of where you might land on how much the flaw was malice vs ignorance, in either case review would have caught it with very high probability had there been any.

As a request, please avoid invoking my name in discussions. I know people mean well but If I make an argument you find persuasive feel free to just restate it in your own words, without attribution.  I've had more credit than anyone needs in a lifetime, and invoking me just inspires asshole responses like the one there and I am really beyond tired of being shit on.

It looks like they need to push a 3.7.0 for all the other libbitcoin projects as well, so they are doing that, and according to the Github issue, they just finished doing that so I'd expect the release to be back up later today.

But this also highlights the dependency hell that is present when building the libbitcoin projects which pretty much affects all of them except for libbitcoin-system. At least the CI/CD system correctly detected the build failure.

Likely these other project releases will have no new commits themselves.

And today v.3.7.0 was removed[1] due to dependency problem.


On branch version3[2], there's only single commit which remove bx seed command[3] though.

[1] https://github.com/libbitcoin/libbitcoin-explorer/issues/730#issuecomment-1678516313
[2] https://github.com/libbitcoin/libbitcoin-explorer/commits/version3
[3] https://github.com/libbitcoin/libbitcoin-explorer/commit/aa46ce63ceced3d8e9e7a2992f404b4b0d494950

Don't bother. Most of the commits are for a new major version of libbitcoin explorer (v4), and I doubt that they just released this version with all those changes on a short notice since the master branch is non-buildable according to the README.

bx seed was already removed in the master branch a while ago, according to Milksad, which also says it was renamed to bx entropy. So I'd be concerned if they just cherry-picked that commit and made a new release out of it.

The fact that the author has been resolute in the position that this wasn't an error means that this can't just be understood in terms of how easy it is to screw up.

Yesterday a new release v.3.7.0 of libbitcoin-explorer has been published on their Github repo, effectively making bx seed an obsolete command and removing it. I'm not knowledgeable enough to sift through all the commits from previous release(s) to this one to identify if major improvements with entropy handling were done. My gutt feeling: I doubt it.

At first glance the removal of bx seed doesn't look to change anything regarding the questionable PRNG and its seeding issues. But, I'm no code reviewer and I didn't have time for a closer look. For me this raises rather questions than any confidence in this tool or how this project deals with entropy, quality of randomness and so on.

When reading "Mastering Bitcoin" I remember that I thought how versatile and interesting this bx tool seemed to be. I wanted to play with and explore it, don't remember what kept me from doing it, though. Today I'm glad I didn't use it.

This reminds me to look at and assess carefully how tools implement the very basic foundation of cryptography to avoid such fails like MilkSad. Unfortunately that's often kind of expert level playground. It's so much more easy to screw up than the opposite.

It does, it makes the random number generator thread specific. See the code after "// Maintain thread static state space.".  Of course it could have made the RNG thread local with a much smaller commit which changed nothing except the fact that each thread got its own copy of the RNG.

disclaimer: i'm the wrong person to speak about thread safety, not enough experience

...but, the pull request doesn't seem to make any changes that should alter threading behavior, if it does it's incredibly subtle (which I appreciate is often the case with thread-safety bugs)

..surely (yeah, another "...surely...") it's good practice to document the nature of the bug, in the case where it's a subtle thread-safety bug?

---

sounds like I ought to check if Armory's use of libbitcoin could be affected. I didn't create any new Armory wallets since the date (late 2016) of the libbitcoin-system pull request, but possibly others did. Armory previously used Crypto++, which I guess was subject to a little more scrutiny (guessing isn't good enough however, I feel compelled now to check)

No. libbitcoin is split into 11 different repositories, the flawed rng was in libbitcoin-system, used all over the place the supposed thread safety bug that motivated the change was observed in P2P networking.  But I believe bx-seed is the one and only generate-your-private-key thing in the whole caboodle.

The division of the software into many repositories probably contributes to the lack of review/oversight and wider participation in development there.

the bad odds are that people are good at re-inventing bad ideas by dint of hubristic assumption that they're being imaginative/original. you can bet someone will go for security<-->obscurity simply because they have some exotic or old platform that they believe somehow protects them from attacks, and use it to generate seeds and/or sign txs offline etc. I realize this is many layers of (now anachronistic) hypotheticals in the case of bx-seed though, but these things bear repeating every so often



hmmm, but wasn't the low-entropy seeding limited to the bx-seed codebase, or has a similar problem been found in the libbitcoin dev toolkit?

I think there are good odds that for any platform where the code can actually be built that function just read randomness from the OS, but you're right that it isn't guaranteed.

Basically it seems they changed from code that had security problems in theory but usually not (and maybe never) in practice to code that was certainly broken all the time for everyone in both theory and practice.

But there isn't any test it's used for I can find, and its used in all the documentation any place a seed is needed. I also can't find any instructions in their docs on how you *should* generate the seed.  Like if you want to use dice you still need a procedure to de-bias the dice (and to get hex out). I don't buy it, it's just not a credible excuse to me. To be clear, I'm not suggesting that it was intentionally vulnerable, but that it was just mistaken and that a rather non-pragmatic view on what users will or should do caused it to not get as much care as it ought to have.

It's also likely bad for the non-cryptographic usage in libbitcoin. An attacker can observe some of the choices made by the software you can recover the RNG state then use it to predict the random choices that were used and will be used, which likely results in DOS vulnerabilities.

On modern computers there is seldom a reason to use very poor randomness.  The only time these days when I use non-cryptographic randomness is for the inner loops of optimization search code where the RNG is very performance critical.  In those cases I'll use xoshiro256++ periodically seeded with rdrand (the hw RNG on modern cpus). But in any ordinary software it's uncommon for the rng performance to matter so much that you can't use a cryptographic one.

Maybe in some usage or another using a crappy PRNG with weak seeding wouldn't be harmful, but it's usually not worth the cost of figuring out if its safe or not (and making sure it stays safe as people change code), better to use a safe thing unless and until the performance is an issue and then figure out if something faster can be used safely.

I don't think there's any. If they wanted to just use it as a unit test for their seed generation algorithm, they should've left it at that and not make it a public API or command.

i defer to gmaxwells point on this: what non-real-world usage is there for a woefully insecure wallet seed utility?

That gives 220,752,000 possible seeds if we take exactly 7 years, otherwise a little more or less. Either way, it's something that even a Pentium 4 can brute force. To say nothing about GPUs.

They clearly did a bad job explaining that this command is not intended for real-world usage.

these statements are rather damning taken altogether. the library author was at best absurdly negligent (that's absurdly), and I say that given that he seems to be otherwise intelligent, as well as just a little arrogant when talking live (which I experienced once). whatever the excuse, it would be difficult to trust someone like that (but i expect he will melt away into the background somewhere/somehow and it will never trouble his reputation as a developer)

---

looking at the diff in the pull request, my (non-expert) opinion is that the original code was also pretty dubious for securely seeding an RNG (src/utility/random.cpp:39-41). depending on the output of std::random_device is clearly implementation/platform specific, wouldn't it have been much more sensible to at least use some cross-platform library function to collect additional entropy? (even simply openssl, surely?). trusting the hardware and the c++ lib implementation on every possible platform (past, present + future...) seems to border on reckless to me, in my (as i say) non-expert opinion

and that's without considering the actual (uncommented) change to cast the current system time (!) to an unsigned 32-bit integer as the return type for the function providing the entropy seeding data. I'm 100% confident that you don't need to be an expert to see that this is staggeringly unprofessional, rock-bottom basic tutorials for generating entropy describe exactly this sort of practice as badbadbad


in fact, ISTM it's not even necessary to search the entire 32-bit number space?! surely it's possible to feed unix-timestamps since the 2016 date/time when the PR was merged into some common c++ mersenne_twister implementations to find every seed generated with the insecure code. either way, it's very surprising that it's taken 7 years for anyone to notice

They made a similar post on reddit, I responded with some questions but they haven't responded.

If I had to make a bet I would bet they actually used bx to generate their seed and are confused about the history.  I very much would not be surprised if the bitcore software were vulnerable (considering the history) but having the exact same vulnerability seems unlikely.

It seems really credible to me that someone could generate their bip39 seed with one tool and think it was another-- they might have even evaluated both.  I think that's more likely that the bitcore code containing the same vulnerability.