"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 dangerous because it uses an insecure PRNG with a 32-bit seed. The audience for a warning doesn't know that, so you have to forget what you know and read it from their perspective.
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." That makes sense, right?
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? It doesn't help the user because they'll just get robbed it they use it. Even if the user is just testing stuff it's no harm to use a plausible secure random seed, and no easier to use an insecure one (it's not like it had an option to let the user give a number between 1 and 4 billion to get a particular result for test reproducibility).
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": look mah, no code!
How could a user distinguish the "You really should use this" from a "you really SHOULDNT 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 e.g. "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
REAL ULTIMATE POWERTRUE 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. 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.
[Aside: Inside Bitcoin core there are some RNGs used for non-security purposes but they use names like "insecure_rand()" to avoid confusion, even though the only users of these internal APIs are developers of the software itself (and, I think these days, they're all an actually secure fast CSPRNG, they're just not intended for security purposes) and are much less likely to get confused than a user at the command-line]
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 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.
All commands in libbitcoin explorer must have their entropy provided to them, so the documentation for bx-hd-new
tells you to use "bx seed" to get it (just like the example above for BIP39, or for
plain private keys).
(... I find myself wondering if 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.
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.
