Using hashcat for collision attack

Question

Whenever i tried generate √N randomly(possible combinations of password length), i always find few collisons of the hash password no matter the length, if the password was made of entirely random characters of course, so i test this case on hashcat. I noticed its generate method always keep some digits intact & try all other positions possible combinations like this

caefnNHJKn854557 --> plOcmawJKn854557

This make the chance for collison to happen very low. Is there any way to set up or configure hashcat to generate an entire random combinations eachtime it try candidates?

i tried the expriment with C++ & C# using their random generator function & many times got the collision. i want to try this with hashcat because its random generator was the fastest but don't know hot to configure it

Answer 1

For any halfway decent hash function, even hashes that are completely unsuitable for cryptography, if you look for collisions by brute force, it doesn't matter how you explore the search space. Keeping a fixed prefix and changing the suffix, or keeping a fixed suffix and changing the prefix, are as good as any other method. That's because all hash functions are designed to produce distinct results for similar inputs.

If there are N possible hash values, you need about to calculate and store about √N hashes until you have a good chance of finding a collision (the birthday bound). For a 32-bit hash as used in hash tables, N = 2³² so √N = 2¹⁶ which is reached very quickly. For a 128-bit hash such as older cryptographic hashes, √N = 2⁶⁴. A GPU these days can calculate something like 2³⁴ (16 billion) MD5 hashes per second, which means it calculates 2⁶⁴ hashes in about 2³⁰ seconds ≈ 34 years).

But that's not all: to find a collision, you need to store the result of all these calculations, so the limiting factor will be memory bandwidth. And once your RAM fills up, that'll be storage bandwidth. You aren't going to find a collision in a 128-bit hash in your lifetime.

Hashcat is designed to find hash preimages, not to look for collisions. Hashcat is designed to reverse password hashes (and ordinary hashes that are misused for passwords), and collisions are not relevant for that. But even with an optimized tool, what you're trying to do is not feasible for any cryptography-sized hash.

If you want to find a collision for a 128-bit hash, you need to understand its structure. There are known methods to find collisions for MD4 and MD5, for example. These methods are practical because they don't use brute force over the whole search space.

By the way, you're calling the hash inputs ”passwords“, but password hashes are different from “ordinary” cryptographic hashes. They're slower, and salted. The use of a random salt means that with a password hash, you don't get the same output twice, not even if you use the same password twice.