Hacker News Reader

Comment by SamUK96 | Hacker News Reader

I'de say it's quite deliberate. Giving the consumer horde better SHA calculators is not necessarily a good idea.

A lot of the theory behind making hasher functions strong is the assumed sheer expense a hypothetical brute-forcer would incur in buying the hardware. If Intel and every myChip Corp. releases chips with better SHA calculators, you'd be risking a global "hacking" frenzy and a potential global meltdown.

The other reason of course is the NSA and the US deep state strong-arming chip makers to keep the general consumer from getting access to fast SHA calculators, since then they can get "private" chips made just for them so they're computationally ahead of the brute-forcing curve.

I mean it's not a big leap to think that, they've already been bribed into the IME...

View on HN

We detached this flagged subthread from https://news.ycombinator.com/item?id=14566906.

A consumer GPU will already beat the pants off of any hardware SHA-3 implementation in the CPU for brute-forcing purposes.

Replace Intel with nVidia or AMD, it was an exemplar manufacturer showing that big chip-makers _can_ do shady things.

But nVidia and AMD haven't sabotaged their chips to be bad at hashing (it wouldn't surprise me if they did the opposite back before ASICs thrashed the GPU bitcoin mining scene) so I don't see how your point transfers. The Powers That Be also haven't put a damper on bitcoin mining ASICs for that matter, which can do precisely one thing: calculate lots of SHA hashes faster than any other hardware.

If there's a shadow war over SHA hardware, the deep state is failing miserably.

The thing is, from the Snowden leaks, we _know_ that the NSA relies on being the most powerful hasher to identify people and things as they do. As I said, it's only a possibility that they could be actively trying to damper _consumer_ (not ASICs) SHA hash rates.

But it's unlikely. It's just a motive for them really.

SHA3 is a hash function, not a KDF.

SHA-3 in XOF mode can be used (and was expected to be used) as a KDF. XOF mode is part of the NIST SHA-3 standard.

SHA-3 is incredibly versatile. This obsession with speed is unfortunate. It's a great function. If you've ever implemented SHA-3, it becomes obvious that all of these modes are simple changes in parameters to the core Keccak function--basically either changing the number of rounds or changing the output window size. And many of these degrees of freedom of Keccak are standardized as part of the NIST SHA-3 standard.

Contrast that with the BLAKE family of hash functions, which all involve substantial changes to the core routine. It didn't have to turn out that way as the original BLAKE proposal was quite versatile, but the downside of being passed over for standardization is greater susceptibility to fragmentation.

Once the core SHA-3 routine begins to see hardware support all of this handwringing and bikeshedding will be forgotten. Choosing SHA-3 today is a solid choice and should be beyond reproach, whereas not choosing SHA-3 should require a substantial and continued defense.

Also, it should be pointed out that the excessive security parameters of the standardized hashing modes will likely be considered prescient once the era of quantum computers is firmly established.

That doesn't mean you wouldn't want to be able to brute-force it (in theory). If you're dealing with a data format where you can easily write garbage to a few bytes (e.g. executables) brute forcing would let you find a useful collision.

Of course a hash function that won a NIST competition a few years ago has nothing to fear from bruteforcing via a specialized CPU instruction :P

If your concern is an attacker that can do 128 bits of work, you've got other problems (like reality).

> A lot of the theory behind making hasher functions strong

I said it was a hasher function already?

His point was that cryptographic hash functions can be designed to be both slow or fast for different purposes. Key derivation functions and password-hashing functions like bcrypt and PBKDF2 are designed to be slow to mitigate brute-force attempts. But general-purpose hash functions like SHA-3 are not designed to be slow; in fact, you'd rather they be fast, because they're designed to be used in e.g. MACs.

In general, cryptographic hash functions are designed to be computed quickly, and key derivation functions are a special subset with greater difficulty requirements designed to be computed slowly. Your comment conflated the two, hence the parent's response.

https://www.youtube.com/watch?v=zrWoG8IckyE

Reply on news.ycombinator.com