11 comments

[ 5.8 ms ] story [ 33.4 ms ] thread
Let's ignore for a second the question of security (is it collision/pre-image resistant? Dieharder says nothing about this).

As a developer, is the fact that it only uses S-boxes supposed to be beneficial to me somehow? Does this mean it runs faster? Uses less memory? Is it an academic exercise? Why would I use this over a different hash function?

It's not even resistant to added \0, so you can trivially create an arbitrary number of collisions.

It fails all smhasher tests and is pretty slow. There's a reason other hashes do more than just sbox mixing. It's a proof of concept of a bad hash function. But it works fine on javascript, I guess.

It's probably an academic exercise (perhaps to demonstrate how not to make a secure hash function). It's is pretty poorly designed.
As someone who knows a bit about how hash functions work and what properties they are supposed to have when well-designed, but has no knowledge of how to invent them: would you elaborate either directly or with links? What about it is poorly designed? Why? What would make it better?
Sorry - just saw this!

So think of the sbox as a function. What happens if you apply the function over and over again? The order of a group like that would be small (particularly since the sboxes are random).

Also, the output space of the hash function would be quite restricted as a result of the group order being low.

I'm reasonably sure it's in jest:

""" I went to random.org and generated 32 sets of 256 no-repeat numbers between 0 and 255 inclusive. """

We have someone with the practical cryptographic knowledge to design their own cryptographic code, but they grab their random numbers from a website... ;)

Also posting dieharder results as validation (and the only kind of validation!) smells like a joke.
I sincerely hope the author will urgently and clearly mark the repo as a toy/demo/do not use for anything important in the readme.