Comment by red_admiral | Hacker News Reader

Comment by red_admiral | Hacker News Reader

Parent Full thread

The crypto is far from ideal.

The situation is very similar to password storage, where you want to not make it trivial to brute-force moderate-entropy passwords even if your database gets breached. We have functions designed specifically for that: scrypt, argon2 etc. https://www.npmjs.com/package/scryptsy is a pure JS implementation of scrypt for example.

Even with scrypt the situation is not great, but using sha for this kind of thing is no longer state of the art. If people are willing to (a) download and run a program rather than rely on the browser and (b) willing to wait half a minute or so for the result then you could easily tune the scrypt/argon parameters up to 11 but at the cost of quite a bit in the way of usability. If "must work on smartphones without extra app downloads" is a requirement you're pretty limited in what you can do this way.

Another solution might be to use real servers but host them on the "dark web" - get Tor a bit of publicity in Catalunya!

EDIT: in response to a few posts that briefly appeared and then disappeared again - IPFS is fine. SHA256 for authenticating a page is fine. I'm only objecting to using raw SHA-anything as a key derivation function as in the section "A static database".

I'm not sure what you mean by "the crypto is not ideal"? I was under the impression that there are not yet collisions for SHA-256 https://github.com/ipfs/faq/issues/22

Only for SHA-1 (which has 160 bit hashes) https://en.wikipedia.org/wiki/SHA-1#Attacks

The attack mentioned on the page is brute-forcing someone's details from partial information:

"it can be used to “fill the gaps” of information about any citizen. If you know someone’s birth date and the area where they live, you can obtain their government ID by trial-and-error on that website."

The mitigation is slowing down the number of guesses/second that an attacker can try. In a well-designed key derivation function, an attacker with 100x the resources should only be able to try out guesses 100x as fast. That's what scrypt/argon2/bcrypt/PBKDF2/... try and achieve.

SHA and other general-purpose hash functions tend to be easy to parallelize, at least in parts, and you can get huge speedups on GPUs or even better, FPGAs/ASICs. That's why no-one serious still mines bitcoins on CPUs and the big mining syndicates [hire planes](http://uk.businessinsider.com/cryptocurrency-miners-rent-boe...) to ship GPUs a little bit faster.

This has nothing to do with collisions. It's to do with hash functions being designed to be fast, and key derivation functions are designed to be slow and memory-hard.

Thanks for the clarification. That makes sense now.

Holy shit! People are hiring planes to ship them GPUs!?

Jeasus!! Gibson was far more prescient than acknowledged;

"the future is already here, but not evenly distributed yet"

Wow...

I had such opportunity and ability to buy bitcoins in 2012... and I missed that boat.

I downloaded the Bitcoin mining app in 2010, opened it once, got bored of waiting for it to sync with some server, then shut and forgot about it for a few years. It might be a funny story to tell my grandkids if BTC is still around

If Bitcoin is around when your grandkids are of age, even this minute might be a great time to buy Bitcoin. Why miss the same boat twice?

Hope what you say is true, because I bought bitcoin @ $4700 :'(

Like they say; "The best time to buy bitcoin was yesterday. The next-best time to buy bitcoin is now."

This isn't as big a deal as it sounds. https://news.ycombinator.com/item?id=14887929

No, they’re not. They’re just overnighting large shipments of GPUs with carriers that use airplanes to handle overnight shipping.

That quote also isn’t from Gibson. :)

> I had such opportunity and ability to buy bitcoins in 2012... and I missed that boat.

You also have opportunity and ability to buy bitcoins now. And, just like in 2012, you have no idea what the price will be five years into the future.

Yup. For one example of a software package that can use GPUs to accelerate password cracking and hash brute forcing, folks can look at hashcat: https://hashcat.net/hashcat/

Just fill 9/10 of database with plausible crap. It would be pretty useless to brute-force it (and any part of it) then.

Scrypt is tweakable for RAM and runtime constraints. From that PBKDF, it would make sense to use something like HMAC-SHA2 with another magic nonce, and then private information plus previous PBKDF output hash together as the authenticated part. If you want to get really tricky, add another random secret hash.

And, they probably should’ve used HMAC-SHA2 to derive the public primary index key insead of a hash function directly.

Reply on news.ycombinator.com