Is this a replacement for SimpleCrypto on NPM?
Show HN: Discohash – Fast Hash
31–40 of 44 posts
Re: Show HN: Discohash – Fast Hash
#32Is this a replacement for SimpleCrypto on NPM?
No because I think that library is for encryption. This is for hashing.
Re: Show HN: Discohash – Fast Hash
#33Earlier quoted context omitted.
Great question, and thank you, Salvatore! Some reasons for that are: different hashes for s and s\0 (without explicitly using length) to make it harder to create collisions, related to as you say better distribution/avalanche for short strings, also design-wise I like the asymmetry that strings not perfectly divisible by 8 will be treated a little differently. I just think that makes it better overall.
Thanks for the replies!
No probs. I think your idea of unifying the two loops is a good one.
A new version that uses the idea and overcomes the challenges would be great, and would simplify the code even more.
If you had a way to make a start on it, I welcome your PR.
Re: Show HN: Discohash – Fast Hash
#34Simple hash, 128-bit mixing function is just: mix(const int A) { const int B = A+1; ds[A] *= P; ds[A] = rot(ds[A], 23); ds[A] *= Q; ds[B] ^= ds[A]; ds[B] *= P; ds[B] = rot(ds[B], 23); ds[B] *= Q; } with P and Q prime.
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 128-bits?
How should I say it?
Re: Show HN: Discohash – Fast Hash
#35This is a hash designed for non-cryptographic use, like in hash tables or bloom filters. You can tell by their small output size, which greatly reduces the cost of a brute-force collision search. It's also in the linked readme. Hash function families with a similar target usecase include: cityhash, falkhash, farmhash, FNV, meowhash, metrohash, murmur, t1ha, wyhash, xxh. The SMHasher suite tests hash functions for spe…
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/
SipHash is considered acceptable even for cryptographic use cases (MACs)
Re: Show HN: Discohash – Fast Hash
#36Earlier quoted context omitted.
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 128-bits? How should I say it?
Hi Cris! First of all, I love to see new hash designs, it is great!
The standard disclaimer is “please do not use this for cryptographic purposes,” placed at the top of the README.
(I like to add a hint afterwards, like “If you need security, please use BLAKE3.”)
Second, if you do want to make a version in the same family with cryptographic properties, a few things are expected:
• Careful list of cryptographic claims (is it a PRF? a PRP? a compression function? is it collision resistant? with what probability of success?…)
• A published paper with preliminary cryptanalysis. What is the average number of evaluations of the hash function for key recovery? How much probabilistic information of the state bits can be gained from the output? How much output leads to a state recovery? What is the worst statistical bias of the output from single-bit input changes?
• Multiple rounds. The production hash should use at least one more round than is shown to be cryptanalytically safe; ideally twice.
• I worry that multiplication, in particular 128-bit multiplication, is subject to timing attacks. It is uncommon to see it used in cryptographic hashes.
Disclaimer: I am not a cryptographer by trade, so this advice is insufficient.
Re: Show HN: Discohash – Fast Hash
#37This is a hash designed for non-cryptographic use, like in hash tables or bloom filters. You can tell by their small output size, which greatly reduces the cost of a brute-force collision search. It's also in the linked readme. Hash function families with a similar target usecase include: cityhash, falkhash, farmhash, FNV, meowhash, metrohash, murmur, t1ha, wyhash, xxh. The SMHasher suite tests hash functions for spe…
> 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 collisio…
heh. Funny
> it is not designed for cryptography even if you extended the output to 256 bit.
You don't know that.
> This is similar to the issues
Can you break either of these?
> Making fast non-cryptographic hash functions is a fun challenge
Fun challenge? I checked out your portfolio and I didn't see any.
> I appreciate the projects
I didn't see your star. It seems more like you're jealous. And trying to make yourself feel better how about your imposter syndrome, by saying someone's work is not all that under the disguise of a public service.
For a "smart guy" that's a little easy don't you think?
So how about this, I've got a fun challenge for you. Have a shot at breaking either of these, because if you can't, you can't really claim it's insecure, can you?
Re: Show HN: Discohash – Fast Hash
#38Stay away. The author can't tell the difference between a cryptographically secure hash and a regular one, claims that simply going from 64 to 128 bits will make magically make this cryptographically secure, and then benchmarks it against actually cryptographically secure hash functions (blake3), which are almost necessarily slower than generic hash functions. Look at meowhash and wyhash instead for the latest and gr…
> Stay away. The author can't tell the difference between
Okay little Mister Can't-Create.
Before you go sounding off, you break it. Then you can talk big. How bout it?
Re: Show HN: Discohash – Fast Hash
#39It is fast hash sure, but it still only sits in the middle of the pack in smhasher results, which is not very impressive. The code is maybe bit simpler than some of its competition, but to my non-expert eyes its still not trivial, and the compiled code still seems as big as some of its competitors. Although I'm bit curious why there is no "size" result in the smhasher table for this hash? http://rurban.github.io/smha…
> 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.
Re: Show HN: Discohash – Fast Hash
#40Stay away. The author can't tell the difference between a cryptographically secure hash and a regular one, claims that simply going from 64 to 128 bits will make magically make this cryptographically secure, and then benchmarks it against actually cryptographically secure hash functions (blake3), which are almost necessarily slower than generic hash functions. Look at meowhash and wyhash instead for the latest and gr…
Can you break this? If no, so your claim is basically hot air, is that right?