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 likely to be exploitable, but I wouldn't bet my money on it.
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.
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).
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.
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.
No intent to change. The tweet confused about thinking this was some third party wallet using libbitcoin.
Instead, from the writeup it appears that at least some of the users followed the above BIP39 seed generation instructions to generate a seed that they used with other assorted BIP39 compatible wallets such as typical hardware wallets.
That's really a C related comment and all it doing is subbing in implementation specific pre-standard versions for the benefit of compatibility with compilers prior to the introduction of the feature in the C11 standard.
The standard calls it "_Thread_local", pre-standard MSVC/icc(win)/borland called it __declspec(thread), and pre-standard GCC/icc(linux)/clang/sun called it __thread.
Code would also be free to just use _Thread_local and say that a C11 conforming compiler is required.
https://github.com/libbitcoin/libbitcoin-system/pull/559
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 likely to be exploitable, but I wouldn't bet my money on it.
https://twitter.com/evoskuil/status/1688657656620167169
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.
https://archive.is/A7Jn6
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).
https://archive.is/HDe8h
Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys.
https://archive.is/fhm5J#selection-12915.2-12915.10
Current libbitcoin-explorer instructions telling users to use the seed command to generate BIP39 seeds (also private keys).
https://archive.is/PWLKJ
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.
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.