Why Combinator is not making all possible combinations?
(06-11-2017, 05:45 PM)Flx Wrote: Is there any restriction in single password length? I noticed that Combiner is dropping passwords when they are longer than 36 signs.

found this also: https://hashcat.net/wiki/doku.php?id=fre...ese_hashes

What is the maximum supported password length?

There's no easy or general answer. Thing is, it depends on many factors.
First let's try to answer why is there such a limitation at all? The answer to this one is more simple: Because of performance! We're not talking here about a few percent. It can make a difference between 0% - 300% so we have to be very careful when we decide to support longer passwords. For example when we dropped the limitation of 16 characters in oclHashcat-plus v0.15 it had the following effect on fast-hashes:
  • Zero-based optimizations: Many algorithms can be optimized based on the fact that zero values in arithmetic or logic operations do not change the input value. With a password limit of less than 16 characters, it was guaranteed that values for positions 16-63 were zero, allowing us to omit dozens of operations from each step. These optimizations can no longer be used. See Passwords13 presentation: http://hashcat.net/p13/js-ocohaaaa.pdf
  • Register pressure: If a password is 15 characters or less, we only need four 32-bit registers to hold it. But as we increase the length, more registers are required. This can slow down the entire process if more registers are required than accessible, as the compiler has to swap out data to global memory. Supporting passwords longer than 15 characters increases register pressure.
  • Wordlist caching: hashcat handles wordlist data in a very unique way. The words are not simply pushed to GPU from start to finish; they are first sorted by length. This is done because many algorithms can be further optimized when all of the input data is the same length. This required a lot of host memory. Depending on the number of GPUs we have and the specified -n value, oclHashcat-plus easily allocated 16GB of host memory or more. This buffer would have been increased 4x since we wanted to increase from a maximum length of 16 to a maximum length of 64. In other words, our host system would request 64GB of RAM!
  • Branching: Many (nearly all) hash algorithm support any password length as input. To do this, the password is split into blocks of a specific size, for example 64 byte for MD5. The hash computes the first 64 byte and then uses the resulting digest as initialization value for the next 64 byte, and so on… To be able to do this, it has to branch (means using if() statement) and GPU's hate branching
Now what are the real maximum password lengths? This is something that we change from time to time. For each hash-type you can say the following: Whenever we find an optimization that allows us to increase the support, we will do it. Generally speaking, the new maximum length is 55 characters, but there are exceptions:
  • Limitation from the hash itself:
    • 1500: 8
    • 3000: 7
    • 9710: 5
    • 9810: 5
    • 10410: 5
  • For slow hashes:
    • 400: 40
    • 500: 16
    • 1600: 16
    • 1800: 16
    • 2100: 16
    • 5200: 24
    • 5300: 16
    • 5800: 16
    • 6300: 16
    • 7400: 16
    • 7900: 48
    • 8500: 8
    • 8600: 16
    • 10300: 40
    • 10500: 40
    • 10700: 16
    • 11300: 40
  • For fast hashes, the important factor is the attack mode:
    • attack-mode 0, the maximum length is 31
    • attack-mode 1, the maximum size of the words of both dictionaries is 31
    • attack-mode 6 and 7, the maximum size of the words of the dictionary is 31
Just to make this clear: We can crack passwords up to length 55, but in case we're doing a combinator attack, the words from both dictionaries can not be longer than 31 characters. But if the word from the left dictionary has the length 24 and the word from the right dictionary is 28, it will be cracked, because together they have length 52.
Also note that algorithms based on unicode, from plaintext view, only support a maximum of 27. This is because unicode uses two bytes per character, making it 27 * 2 = 54.

Messages In This Thread
RE: Why Combinator is not making all possible combinations? - by dmanyep - 10-19-2017, 08:13 PM