4 ms·
Um, not sure what you aim to solve here. You are effectively increasing collision risk by an arbitrary amount by running hash output as input to a crc algorith
by shzhdbi09gv8ioi 3y ago
Um, not sure what you aim to solve here.
You are effectively increasing collision risk by an arbitrary amount by running hash output as input to a crc algorithm.
Kids, don't roll your own security.
- skinkestek 3y agoI think you misunderstood: This is if you compare two hashes and they look really similar but you want to be really sure. Of course a real equality check is better but visual check of original hash + this is better than visual check alone.
- shzhdbi09gv8ioi 3y agoAh, thanks. Yes, I did not understand this properly.
- ijustlovemath 3y agoA similar technique is employed by git to get past SHA-1 collision risk, so I wouldn't say it's entirely without merit.
- atoav 3y agoBefore: two hashes that might pass a manual check After: four hashes that don't pass a manual check The short ones are there so you can easily spot the collision in the long one, even if the start and the end are the same. If you read just the short ones your criticism applies, but that was not the idea. You read the long one first, then the short one. This is a logical AND not a logical OR, thus it gets harder to make both collide at once (because there are less similar looking values for the first one that produce the same values in the second one + your attacker might not know which one you are using). Maybe if you read my comment, you will also realize I pointed out that CRC8 is the wrong choice for this, but I was on my phone and this was the hash calculator I found first.