Milk Sad Disclosure
milksad.info
milksad.info
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.
EDIT: It loops around to 0 every 4.something seconds, so it's not like everything after 4 is the same key. It's just a more random distribution than what you may be thinking.
so it's not even 32 bits of entropy, it's some tiny fraction of that. (system times for a few years interval)
"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."
"Tony Story" has you laughing straight out of the gate. Billed as an action-comedy, it's the ultimate clash of the titans between machismo and mirth.
The film follows our hero, Tony, a middle-aged man who wakes up one morning to find himself inexplicably transformed into a small plastic action figure. The plot thickens as he learns he's the star of a beloved, but sadly discontinued, line of 90s toys.
Tony is forced to navigate the wild world of suburban backyards, dodging ferocious pet chihuahuas and the sticky hands of sugar-fueled toddlers. His quest for a return to normality is as hilarious as it is heartwarming.
The brilliant use of slapstick humor, a dash of existential dread, and a sprinkling of well-timed puns are skillfully mixed into a cocktail of laughs. The film's standout moment involves Tony, a malfunctioning Roomba, and a perplexed cat, in a scene that will leave you in stitches.
The voice acting is second to none, with Tony's gruff, action-hero voice (think Clint Eastwood meets Optimus Prime) contrasting hilariously with his miniature plastic form. The supporting cast of misfit toys, including a neurotic yo-yo and a sassy Barbie doll, add to the hilarity.
"Tony Story" is a wild roller coaster of laughter that reminds us all not to take life too seriously. As Tony himself puts it, "I may be small, but my problems sure aren't!" This film truly delivers a unique blend of comedy and action that will leave you chuckling long after the credits roll.
Awl sew, thee spiel checquer frowned know tissues bee four eye clacked.
I think people pick it because it has a cool sounding name.
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.
Sorry about that, my bad, I though i understand how that works, when I was exploring this topic i literally asked everyone i know and no one seemed to have any idea, and then when i felt i got a conclusion i was happy i found some explanation.
Anyway that just an excuse at the end of the day.
I have added to the thread a screenshoot of your reply and link to this conversation.
https://twitter.com/raw_avocado/status/1689317198626422784
Thanks for clarifying that.
Owning Bitcoin is like paying into an involuntary bug bounty program. Every time someone finds a bug, your life savings get wiped out.
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 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".
Not sure I would read too much into that. I am sure many people value the community there, but it it ultimately, a web forum around a web comic.
You're doing exactly the "confusing entropy with key length" thing I was mentioning above.
That's not the situation at hand. The entropy in question is the private key generation, it's not related to any SHA256 hash in the protocol. But you're right, if you were trying to generate symmetric keys using a 48 bit password expanded using SHA256 as a PBKDF that would be a disaster. But no software is doing that[1]. All you need to do is pull a key derivation function off the shelf and use it with recommended parameters. Really these have been stable, even bcrypt is still very solid.
Your question was essentially "can a human being remember enough entropy to secure a bitcoin wallet". And the answer is absolutely yes.
[1] What it was doing was even worse, of course.
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.
Also, there was an ethereum wallet with over 40,000 ETH that got drained.
> By examining 300 billion candidate passwords, we found 884 brain wallets that were active at some point in time. Unfortunately, we also found that nearly all were drained – usually quickly. While our findings are necessarily incomplete, they certainly suggest that brain wallets are not a secure method for using bitcoin. Perhaps the most surprising result of our analysis is the relative scarcity of brain wallets in use today. This is actually quite encouraging, because it means that fewer users are at risk to these attacks than has previously been supposed.
I don’t think that logic holds up.
It’s pretty much an entire paper of FUD.
And no, anyone with 400,000 ETH who claims they used a brain wallet, and oppsie .. someone stole it. Is having a boating accident, if you know what I mean.
I'm a co-author of that paper, we later got funding to do a larger cracking run and found more wallets, and even some that still had balances. See slide 18:
https://rya.nc/files/measuring_the_use_and_abuse_of_brain_wa...
Feeding a massive corpus reddit comments and six years of IRC logs into the cracking tool was particularly interesting.
> And no, anyone with 400,000 ETH who claims they used a brain wallet, and oppsie .. someone stole it. Is having a boating accident, if you know what I mean.
It was about 40,000. The password was "guybrush", and I spoke to the guy who made it. He didn't understand how the tool worked when he made an address. Much later, the Ethereum foundation sent him the ETH. It was gone by the time he went to spend it. Dude put out a press release offering to let whoever did it keep half if they gave back the other half. The ETH hasn't moved since the day it was stolen, almost eight years ago.
I assure you, the guy made a genuine fucky wucky.
If I'd gone blackhat with this research, I could be retired to a volcano lair on a private island by now.
WTF is your angle here?
My angle is that simple brain wallets that use a combination of a memorable phrase with some individual information, like the user’s name, birthdate, address and a 4 digit PIN, used as salt, are then extremely secure. And your paper and the original comment I responded to don’t emphasize that it’s the user’s use of such an systen that makes them vulnerable not the foundation of the technique of brainwallets.
Basically you’re blaming the car for the drivers not understanding how to drive and immediately crashing.
That's because it is the foundation of the technique that makes them vulnerable. They are an "attractive nuisance". A system must be evaluated based on "typical use", not "perfect use".
You come across as a social Darwinist who would be happy for all the warning labels to be removed from everything and all safety regulations repealed. The world you advocate for would be an awful dystopia. You have nothing to say I haven't heard before.
I think this more applied to you. You actually invested time to write a paper about brainwallets because some people don’t understand or know how to use them properly. The paper is not logical, if it was then a small POC I know about is all of them, which obviously it isn’t, you can’t find serious people’s brainwallets, they would be salted in a way that it’s hopeless to crack.
You claim brainwallets are fundamentally unsafe, which honestly is total nonsense if you understand them and how they work.
I’m gonna guess you’re a ban Bitcoin type because it’s… wrong or whatever.
The correct way to handle this would be for brainwallet software to generate and provide the user with a high-entropy passphrase rather than asking for the user to provide one. Failing that, it could at least reject very-low-entropy passwords (e.g. impose a minimum 20 character limit).
But even then we're band-aiding the underlying problem, which is that decentralization[0] and finance go together about as well as twizzlers and guacamole. Transaction reversibility is a feature, not a bug, and there's no trustworthy way to implement that sort of thing in a decentralized finance system. Absent a way to dispute fraudulent transactions the only way to avoid your money becoming everyone's money is to overcompensate on preventative measures: i.e. insanely long passphrases stored on hardware keys in lockboxes buried under a garden birdbath.
And sure, yes, we can point and laugh at the credit card industry for treating primary account numbers printed on the front of the card as secure tokens, taking decades to adopt EMV cards in the US, charging horrible swipe and chargeback fees to businesses, and so on. However, there is a reason why, a decade and a half in, people use credit cards and not Bitcoin. Credit cards actually function as a payment mechanism and you are less likely to be defrauded using them.
[0] I additionally dispute the idea that any cryptocurrency system is actually decentralized. The need to agree on the validity and order of transactions necessarily requires one individual or institution actually decide the rules everyone else, with unanimity, agrees upon. Operation of the network is nominally decentralized but the need for security against transaction reordering in the face of no strong identity being available means that practically, it is centralized.
We've seen this with the 'scaling wars' of Bitcoin. Two groups of shadowy puppetmasters - developers and miners - duked it out over absurdly stupid technical arguments regarding how to scale Bitcoin.
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
Eventually taking the weak brainwallets he talked people into creating wasn't enough: He lost his bitcoin (I think via gambling but maybe an exchange hack), whined he was broke for a while, and whined that not many people were making hackable brainwallets, then added a more explicit vulnerability to the site. He vanished after it was caught.
https://www.reddit.com/r/Bitcoin/comments/1zti1p/17956_hacke...
https://www.wired.com/2015/07/brainflayer-password-cracker-s...
> I could find the passwords for 17.956 of the addresses. * Only 2 addresses of the hacked brainwallets are currently not empty, and the total money that I could actually steal is 0.00115215 BTC.
> Somebody seems to have systematically flooded the blockchain with transaction to brainwallets. E.g. this transaction: https://blockchain.info/tx/ba421da33e5f85669d9312b804e22fa4c... It seems that each target address is actually a brainwallet and alphabetically ordered. The passwords for the first 3 addresses are Hollister, hollowing,
Nobody’s real brain wallets are being hacked! It’s just left over traces from someone running aome testing in early days of bitcoin.
This one says 17K wallets … oppsie all empty and obviously programmatically generated! i.e not used for real.
The other paper found 800!! supposedly… all empty.
A well designed brainwallet is perfectly fine and safe, just don’t use a sequential phrase from known sources and modify the words you do. Obviously.
I've talked to a LOT of real people who's real brainwallets were hacked. Certainly there is also some 'testing' but that doesn't change the fact that there have been real and substantial losses.
Brainwallets are very dangerous.
A brainwallet is the same thing as using a user provided password to secure a high value system that has an unsalted and public password hash database. This is a negligent practice. In the corporate world it wouldn't be shocking to learn that a security engineer was instantly fired for implementing such a practice.
Good security advice results in practical security even if the user uses the system less than perfectly. Attacker-originated security "advice" provides security only under unrealistic perfect use. Telling people to use brainwallets is like recommending one-time-pad encryption. In practice the security will be fragile if not outright broken though in theory with it may go okay sometimes.
Correct usage would require secure mechanically generated uniformly random seed phrases with a hundred plus bits of entropy. That isn't generally what people do in practice and the few who have often have issues with retention of the string being inevitably very poor, causing them to lose the funds by forgetting (esp after getting a fever). (Of course, if they're going to write it down and they didn't generate it themselves then it's not something anyone should be calling a brainwallet anymore.)
Especially if the brainwallet adds a salt, which is maybe the problem that the previous poster was referring to. Brainwallets that don't add a salt are definitely a risk.
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.
I'm sure that even with a great statistical model of password haikus (say an LLM) yours would still be one in a billion which still seems unlikely, but a cracking cluster can try billions per second.
In these cases it's very easy to have security that depends on the odds that a powerful attacker just hasn't gotten around to seriously trying the broad class of predictable generation schemes you've used.
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.
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.
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.
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.
.. and receive bitcoin at them.
Wow brutal.
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.
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.
Not that it's particularly worth bothering if you have an 80 core machine and only 13 billion keys to check.
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