111–120 of 133 posts
Seems a bit overkill with a brand + domain name for every new vulnerability. Don't get me wrong, it's a nice find and all, but I'm really distracted by all the fluff.
Eh, let the security consultants have their moment. Also it's a great name. "Running bx seed on 3.x versions with a system time of 0.0 always generates the following secret: milk sad wage cup reward..."
“Wage cup reward” is almost poetry …
The spiciest bit: > 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…
Look at the big warning there: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-se... 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.
Earlier quoted context omitted.
The difference between 32 bits and 64 bits is the amount of people on Earth compared to (EDIT) the amount of grains of sand on Earth. 32 bits is nothing when it comes to entropy, and it can take a security researcher (like us) only $100 to rent a machine to completely brute force it. Nowadays, only values less than 128 or 256 bits (which are exponentially bigger) are seen as appropriate.
You mean time is the only source of entropy there? I don't think number of bits would even matter for it to be bad in such case.
Was the code seeding by seconds since epoch, or nanoseconds since epoch truncated to 32 bits? Broken either way. https://github.com/libbitcoin/libbitcoin-system/blob/a1b777f... const auto now = high_resolution_clock::now(); return static_cast (now.time_since_epoch().count());
Earlier quoted context omitted.
> Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly Sure there is. Have horse batteries taught us nothing? https://xkcd.com/936/ 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 use these passwords all the time. However, you should keep in mind the text in the comic: > (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 economical…
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.
Was the code seeding by seconds since epoch, or nanoseconds since epoch truncated to 32 bits? Broken either way. https://github.com/libbitcoin/libbitcoin-system/blob/a1b777f... const auto now = high_resolution_clock::now(); return static_cast (now.time_since_epoch().count());
Nanoseconds since epoch, which means eventually it does loop around, so at the very least it's not possible to generate a specific wallet by knowing when it was first used.
Earlier quoted context omitted.
[flagged]
That’s not what I wrote, I wrote there were some similarities and listed them, and you presented different differences and discredited those differences as an attempt to discredit me and the entire concept That is called a strawman argument, do better.
Reminds me of attacks people were running on 'brainwallets' a while back - i.e. wallets whose initial key material was just a passphrase you'd remember. The idea was that you could keep the passphrase stored nowhere and not have to worry about it being stolen by... well, any of the 10,000 things out there looking for cryptocurrency keys. Of course, there is no way in hell you can actually make the human brain store e…
> Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly Sure there is. Have horse batteries taught us nothing? https://xkcd.com/936/ 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.
Earlier quoted context omitted.
Here's a thread on how bitcoin core generates entropy https://twitter.com/raw_avocado/status/1445024873382809604
that thread is a little confused: Particularly, 'The Dynamic and Static events are mixed in(mostly) by using " 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 mov…
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.