Show HN: Discohash – Fast Hash (opens in new tab)

> This is a hash designed for non-cryptographic use

The Readme specifically says "you can modify it to yield 128-bits or more if you want a cryptographically secure hash."

Which is a problematic statement, because it is not designed for cryptography even if you extended the output to 256 bit. It's not the output length that makes it cryptographicaly secure. (Rather it's the difference between "you won't find collisions by accident" and "you won't find collisions even if you try really hard using very sophisticated math", but there are more requirements.)

This is similar to the issues with a different hash by the same Github user posted two weeks ago:

https://news.ycombinator.com/item?id=23103521

Making fast non-cryptographic hash functions is a fun challenge and I appreciate the projects, but please, please do not make any claims about cryptographic properties!

All of those mentioned have Hash flooding issues due to invertability or lack of diffusion.

I think SipHash is the better choice for non-cryptographic use cases (e.g. hash tables) https://131002.net/siphash/

I am using Bob Jenkin's one_at_a_time hash for that purpose.

It is really simple and works with unaligned data.

But it is not doing well in benchmarks. I wonder if I should use another one

Was it the inconsistent use of curly braces that made you comment on the code style?

Depends on your use-case and the tradeoffs you're willing to make. SHA1 is slower than the the top finishers of the SMHasher suite [1], even if it's hardware-accelerated. Meanwhile, SHA256 and later are currently considered to be suitable for cryptographic use, so if you're not sensitive to the size of the hash output, you may get additional nice properties that you didn't intentionally design for. But they're even slower.

If you're shipping a black-box component that needs to use hashing internally, and the hash outputs don't leak out of the black-box, consider switching to a faster non-cryptographic hash to gain performance. Consider the implications of switching -- dependencies, trust, performance profile, hash output size, documentation, customer expectation -- and you will have to discard or otherwise invalidate the meaning behind of your past hash outputs.

If you're occasionally applying a hash function and obtain a digest that gets put into long-lived files or records, e.g. you're checksumming your own files for sanity and then verify them later against these records, then you may value availability and stability more than you value performance. If so, don't switch.

If you are fine with the current performance profile, the cost and complexity of switching (or any nontrivial change) may outweigh the benefits of leaving everything as-is.

[1] https://github.com/rurban/smhasher#summary

Are you running into performance issues with SHA? If not, I wouldn't change

Please modify this: "The standard digest is 64-bits, but you can modify it to take 128-bits if you want a cryptographically secure hash."

Just because it's 128-bit doesn't make it cryptographically secure.

Can you break this? If no, so your claim is basically hot air, is that right?

It's odd to have the documentation in a .docx file in the repo. The code itself is not very readable. The core of it is something like (simplified):

    function mix(uint64 a, uint64 b) {
        a ^= secret
        b ^= seed
        hi, lo = mul128(a, b)
        seed = hi ^ lo
    }

It's elegantly simple, but depends critically on 'secret' not appearing in the data.

> DiscoHash is included in SMHASHER [3] but its benchmark results aren't.

They are included, but understandably you missed them because it's also called BEBB4185, stated in README. Find BEBB4185 line in SMHASHER Readme.

Good question on the memory bandwidth. From memory it was a multicore system, so I think that has a higher memory bandwidth than a single core. Thanks for the STREAM thing!

> middle of the pack in smhasher

for all hashes. lot of those top ones are not crypto hashes.

> The ecrypt result is completely irrelevant when this can not be in any way be considered cryptographically secure

Break it first, then you can say that. otherwise, what would you know?

not sure if it's because English is not your first language or just had a grumpy day or something else, this came across veeery negative. Be positive in your comments on work.

if you want to be critical doing so with positivity gives it more credibility because it shows you're able to see both sides. leading people to assume you're more likely making a balanced rather than a biased assessment, whether or not that's true.

No because I think that library is for encryption. This is for hashing.