Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Milk Sad Disclosure

milksad.info

Post reply on HN
Print view View original

71–80 of 133 posts

Re: Milk Sad Disclosure

#71

Post by comboy »

ryanatdistrust wrote: post #18
comboy wrote: post #13

Earlier quoted context omitted.

Why is it a mistake?

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.

Re: Milk Sad Disclosure

#72

Post by comex »

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.info/disclosure.html#libbitcoin-vendor-respo...

Re: Milk Sad Disclosure

#73

Post by nullc »

Some extra relevant links:

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.

Re: Milk Sad Disclosure

#74

Post by nullc »

sparkie wrote: post #55
quonn wrote: post #29

Earlier quoted context omitted.

But the phrases are random, so unlike poems or prayers they are difficult to memorize.

Create your own haiku, never publish it. What are the odds of someone creating exactly the same haiku?

Probably much higher than you suspect. Making password haikus is an obvious idea which has been suggested many times before.

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.

Re: Milk Sad Disclosure

#75

Post by midmagico »

nullc wrote: post #73

Some extra relevant links: 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 exploitabl…

> Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys.

.. and receive bitcoin at them.

Wow brutal.

Re: Milk Sad Disclosure

#76

Post by iraqmtpizza »

kmeisthax wrote: post #11

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…

Encrypting your hard drive is like paying into an involuntary bug bounty program. Every time someone finds a bug, your nudes get posted to the internet.

Re: Milk Sad Disclosure

#77

Post by iraqmtpizza »

codetrotter wrote: post #39
ajross wrote: post #15

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.

This xkcd comic has been instrumental to me. I wrote a command-line utility a couple of years ago that I use myself regularly to generate secure and memorable passwords https://github.com/ctsrc/Pgen 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 will yield a passp…

dibs on joyous embolism outsider evasion mashed. this is my new password

Re: Milk Sad Disclosure

#78

Post by ryanatdistrust »

a-dub wrote: post #59
aidenn0 wrote: post #31

Earlier quoted context omitted.

Would a CSPRNG be at all an improvement with only a 32 bit seed? Couldn't you still brute force it?

i think the bigger problem is that the seed is easily guessed or found, so all the output can be regenerated. so it's not even 32 bits of entropy, it's some tiny fraction of that. (system times for a few years interval)

As discussed elsethread, it used the lower bits of the time value, so while there is is a fraction of the 2^32 space due to precision loss in the OS time calculations, it is not as simple as "between when this software was released and now, in seconds".

Re: Milk Sad Disclosure

#79

Post by fbdab103 »

kmeisthax wrote: post #66
ajross wrote: post #15

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…

>Related: The password hashes for the xkcd forums actually did leak and it turned out most people's passwords were "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.

Re: Milk Sad Disclosure

#80

Post by djbusby »

nullc wrote: post #47
technion wrote: post #38

Earlier quoted context omitted.

Seeing it declared a WONTFIX to me helps answer which of those it was. If it was fraud, you'd expect a fake apology and a fix at this point.

Why? The regress is infinite, it's zero information. A malicious party can anticipate any public-information rational for dismissing their actions and pretend to be whatever flavor of fool you might accept. "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…

This quote is from "The Princess Bride" movie. The actor who spoke this was also, IIRC, the Grand Nagus in ST:DS9. Brilliant in both roles.
Post reply on HN