Quote from: pooya87 on August 10, 2023, 01:49:37 PM

Isn't "bx seed" supposed to be weak? I mean the docs clearly state that this is generating a "pseudorandom" seed and can "introduce cryptographic weakness". Why would a wallet use this in first place?
https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-seed

"It's dangerous to go alone! Take this."

You're reading the "warning" the the benefit of unadulterated hindsight, you already know the function is dangerously insecure. The audience for a warning doesn't know that, so you have to forget what you know and read it from their perspective.

Quote

WARNING: Pseudorandom seeding can introduce cryptographic weakness into your keys. This command is provided as a convenience.

One completely credible way of reading the "warning" is "It's really easy to get seeding wrong and dangerous if you do, to help you get it right we've provided you with this function for your convenience.".

Otherwise what possibly could convenience mean here? A function called "bx seed" that outputs a minimum of 128 bits while never having more than 32-bits of unpredictability, based on the time... how is that convenient for anyone except thieves?

If they didn't want to do anything complicated they could have just told users to use "xxd -p -l 32 /dev/random" or "openssl rand -hex 32".

How could a user distinguish the "You really should use this" from a "you really SOULDNT use this"? Well one way would be for it to explicitly say not to use it, which the warning did not say. Another way is if the page gave even the slightest hint of what the user should do this instead. "You should roll dice for your seed, instructions are outside of the scope of this page."-- but it didn't do that either.

"There was once a little chick named Kluk"

The "you really should use this" understanding isn't the only credible dangerous understanding. Another way to read it is that the output is not TRUE RANDOMNESS, but instead is the output of a securely seeded cryptographic pseudorandom generator. That is what the code actually did (more or less) until late 2016. People sometimes spread FUD over the use of CSPRNGs in favor of often-dubious true random schemes. In fact, comments by the libbitcoin author suggest that this may have been the actual intent of the warning-- as he says it was there to warn users that the code depended on the operating system RNG. The fact that it *didn't* depend on the OS it was just unconditionally insecure and yet the author insists there is no flaw and its working as intended is confusing to say the least (especially since he knew 32-bits could be searched quickly).

But in any case use of the OS RNG (which these days is usually a CSPRNG driven by a hardware TRNG among other sources) would be completely reasonable and unlikely to lose your coins (save for some fringe risks)-- which is dramatically different than what was actually delivered: a function guaranteed to lose your coins.

So even accepting the author's position the 'warning' there wasn't intended to be a warning that it was actually insecure but a warning that it might not be highly secure against fringe threats like your OS yielding bad random numbers. We can't say a function that had no security was adequately warned by a notice intended to address the fact that it it may not have the best possible security.

"It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'."

But all this talk about the "warning" is kind of moot-- the behavior used to be good (more or less) but then in 2016 was changed. The change happened without notice in an unreviewed PR that claimed to make the random number generation "thread safe and optimal". The change could have easily renamed seed to "insecureseed" and/or restricted it to 32-bits of output, but it didn't.

The warning, which was listed only on a single page of the documentation, was added after the change and after the command was already in use and recommended elsewhere.

Other pages of the documentation instruction on the creation of private keys and BIP39 seeds continued to use "bx seed" with no warning. The text advising "bx seed" with no warning was submitted to Mastering Bitcoin by the same person who later introduced the vulnerability. They also listed instructions elsewhere with nary a warning in sight. Even if you don't agree with the the two distinct arguments I present about about the warning being completely ineffectual there is a great reason to expect most users would never see it.

Quote

Or is the problem somewhere in the code affecting other commands like "bx hd-new" because the doc doesn't say anything about being weak there.
https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-hd-new

All commands in libbitcoin explorer must have their entropy provided to them, so the documentation for bx-hd-new tells you to us "bx seed" to get it (just like the example above for BIP39, or for plain private keys).

(aside the unformatted entropy on stdin is may be responsible for some other insecure key incidents we've found-- it's pretty easy to provide the wrong input into stdin and not notice!)

That aside, anyone working on software in this space (or really in general) has to spend a considerable amount of time avoiding serious footguns because otherwise there are too many ways for things to go wrong for any user (even an expert) to have much hope of using the software successfully. A seed generating command that generates seeds which are practically insecure is just unjustifiable, to do so intentionally (or defend an existing one) requires a phenomenal lapse in judgement.

And we've still yet to see an explanation for this the fact that the authors development activity stopped entirely months ago on the very day the first exploitation appear to have happened and how that possibility squares with the denial that there was a problem in libbitcoin explorer at all.

Quote from: Carlton Banks on August 10, 2023, 07:49:44 PM

Anyone who compiles this code themselves (and I'm pretty sure that's necessary, no organization was building + distributing binaries) is taking a leap into the world of trusting their own judgement in any case.

FWIW, there are binaries. I wouldn't be surprised to learn that they were frequently used, as it's long been the case that this software has been difficult to get to compile, as NotATether recently learned.