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.
I think people pick it because it has a cool sounding name.
"Now, a clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool, you would have counted on it, so I can clearly not choose the wine in front of me. ... Because iocane comes from Australia, as everyone knows, and Australia is entirely peopled with criminals, and criminals are used to having people not trust them, as you are not trusted by me, so I can clearly not choose the wine in front of you."
so it's not even 32 bits of entropy, it's some tiny fraction of that. (system times for a few years interval)
Only their products and whoever used them as a 3rd party is affected.
Particularly, 'The Dynamic and Static events are mixed in(mostly) by using "<<" Left Shift Bits. Because it's a binary operation, every digit is a power of 2, so shifting the bit n positions ends up multiplying by 2^n. This adds further confusion when multiple numbers are used at once.' --- the tweet appears to be confusing C++ stream usage of "<<" with shifting (and as a result makes it sound like the code is doing something idiotic).
Here is how it works: Lots of potential entropy sources including the essential good ones (as well as junk ones like timestamps and user/host info) are fed into a cryptographic hash then strengthened with iterated hashing. The junk sources are included as a hail mary so the user might have some chance to move their funds if they learn about vulnerabilities in their OS/hardware RNGs before an attacker can brute force out the weak sources.
Owning Bitcoin is like paying into an involuntary bug bounty program. Every time someone finds a bug, your life savings get wiped out.
Also, there was an ethereum wallet with over 40,000 ETH that got drained.
https://www.reddit.com/r/Bitcoin/comments/1zti1p/17956_hacke...
https://www.wired.com/2015/07/brainflayer-password-cracker-s...
This was one of the best uses of GPUs 10 years ago, people still have those instances running just in case people use “obscure” common phrases from books again instead of mnemonics
Its more like anyone that thought they were clever got swept. There arent statistics, just threads on bitcointalk and reddit
And English is a lot more than 2048 words - so you could probably use a shorter phrase and still be fine.
To get 128 bits of entropy with words, you need to pick about thirteen out of a million words--which is on the order of all the words in the English language--and give all of them equal probability. The sequence needs to be fully random as well. What you end up with will surely be easier to memorize than a UUID, but substantially more difficult than the start of the Lord's Prayer.
EDIT: Math is wrong, I was thinking 10 bits per million instead of 20. So 6-7 words out of a million (whole language) or 13 words out of a thousand (very limited subset of the language). Point about random selection still stands, but it's certainly easier than 13 very uncommon words. Still much harder than a realistic sentence of that length, though.
Sure there is. Have horse batteries taught us nothing?
Don't confuse key length with entropy. A properly-scaled PBKDF remains secure with as little as 48 bits or so. Needless to say, though, a 32 bit time value is hardly a properly designed key derivation input.
I made a little android app using it to generate passphrases, each word gives 13 bits. So 6 words is plenty for a disk encryption password at boot.
I wrote a command-line utility a couple of years ago that I use myself regularly to generate secure and memorable passwords
With this tool you can also see how many bits of entropy the passphrase generation settings you are using will result in.
For example, generating a 5 word passphrase using the long wordlist
pgen -l -n 5
joyous embolism outsider evasion mashed
pgen -l -n 5 -e
Current settings will create passphrases with 64.62 bits of entropy.
My program supports the use of physical dice to generate your password.
Have a look, try it out yourselves :D
> (Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)
This is almost a sound assumption for most web services[1]. However, this is Bitcoin. The only thing the attacker has is your hash. And you're using a payments system which economically incentivizes the creation of ever-larger systems for brute-forcing hashes. The network's hash power as a whole is estimated to be around 331 exahashes per second, so 68 bits of entropy would take one second to crack.
Correct horse battery staple would be cracked in fractions of a second by the full network. Eight common words would take 12 days. If we go further to 12 words, then we do get reasonable levels of security, but I'm assuming hashrates stay constant forever which is a bad assumption. And 12 word passphrases will already be about as much of a pain to remember as the 'password policy compliant' passwords xkcd was railing against.
[1] The most likely attack is actually credential-stuffing, not brute-force. xkcd is assuming you already use separate passwords.
Related: The password hashes for the xkcd forums actually did leak and it turned out most people's passwords were "correct horse battery staple".
No, not four random words. I mean the literal text "correct horse battery staple".
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.
its an interesting attack vector
provide educational resources with compromised examples
wait for dev or their users to deposit funds in the copy and pasted contract or dependency
long game, been wondering how well that worked
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).
These guys are good. Their CTO (or ex-CTO ?) was part of the original FIDO alliance that came up with the U2F spec.
> 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.
> We do not agree with this assessment.
https://milksad.info/disclosure.html#libbitcoin-vendor-respo...
He's right.
This isn't a general purpose programming language, a pile of ore from which you might conceivably construct a footgun. It's a toolkit specifically designed for financial applications with a "leak your financial details" tool built in.
Sure, it's AGPL, they're not literally liable, but it's not great.
Also note that the tool bothers to refuse to use a flag to specify 32 bit seeds, due to their known risks, but then proceeds to give you only 32 bits of entropy anyway even if you ask for 256.
Don't get me wrong, it's a nice find and all, but I'm really distracted by all the fluff.
“Wage cup reward” is almost poetry …
https://github.com/libbitcoin/libbitcoin-system/blob/a1b777f...
const auto now = high_resolution_clock::now();
return static_cast<uint32_t>(now.time_since_epoch().count());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.
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 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).
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.
.. and receive bitcoin at them.
Wow brutal.
Multi signature addresses mitigate this attack vector?
With the “taproot+schnoor” upgrade last year, it is impossible to tell if funds are stored in a single signature vs multi signature address?
That was one of the goals of initial multisignature technology in bitcoin, it was about if one of your devices got compromised you could have 2 factor and not approve the transaction. People werent thinking about if your private key generation was compromised, but it works here too