I see no reason to use rand () here. That would only make sense if you know the seed (as explained in my previous post). Otherwise it would just slow everything down by a lot.
Furthermore, there is no GPU implementation for hashcat for rand ().
No, mask attack is not sequential by default. It uses markov, use --markov-disable to disable it.
I also do not see why you think that a random number generator could not generate a key with 2 or more identical bytes one after the other. If it is really random, the sequence of 2+ identical bytes is perfectly reasonable (even though the amount of keys with a sequence of 2 identical bytes one after the other isn't that high compared to the overall number of keys, the keys that have 2+ identical bytes can't be ignored).
You can only use a filter like this if you know that the key with which the ciphertext was encrypted really had that limitation/filter i.e. that no more than 2+ bytes are the same.
BTW, maskprocessor has an option to limit the number of same bytes next to each other:
But you can see that whenever you use a filter like this e.g.:
that the speed might drop significantely, especially for fast hashes.
Therefore my question is: do you know that the key was generated with a filter/limitation like "no key can contain 2 identical bytes next to each other". If not, it doesn't make sense to limit it like this.
Anyway, bruteforcing a *random* 16 byte key is infeasible anyway, no matter if you add a filter or not (and as we can see, the filter could reduce speed and rand () will decrease the speed even more).
I think the problem is your understanding of "random"... a random key does not necessarily mean that it used the ANSI C rand () function (but maybe you have more details about this and know that the key was generated by using rand (time()) ) ...
rand () is slow and there is no GPU-friendly implementation for hashcat of this.
"random" does not mean that a key with 2+ bytes that are equal, or even all bytes that are equal, could not exist... instead, if the key was generated randomly (cryptographically, truly random) there is no such limitation/filter.
Furthermore, there is no GPU implementation for hashcat for rand ().
No, mask attack is not sequential by default. It uses markov, use --markov-disable to disable it.
I also do not see why you think that a random number generator could not generate a key with 2 or more identical bytes one after the other. If it is really random, the sequence of 2+ identical bytes is perfectly reasonable (even though the amount of keys with a sequence of 2 identical bytes one after the other isn't that high compared to the overall number of keys, the keys that have 2+ identical bytes can't be ignored).
You can only use a filter like this if you know that the key with which the ciphertext was encrypted really had that limitation/filter i.e. that no more than 2+ bytes are the same.
BTW, maskprocessor has an option to limit the number of same bytes next to each other:
Code:
-q, --seq-max=NUM Maximum number of multiple sequential charactersBut you can see that whenever you use a filter like this e.g.:
Code:
mp64 -q 2 [mask] | hashcat -w 4 -m 14100 -a 0 hash.txtTherefore my question is: do you know that the key was generated with a filter/limitation like "no key can contain 2 identical bytes next to each other". If not, it doesn't make sense to limit it like this.
Anyway, bruteforcing a *random* 16 byte key is infeasible anyway, no matter if you add a filter or not (and as we can see, the filter could reduce speed and rand () will decrease the speed even more).
I think the problem is your understanding of "random"... a random key does not necessarily mean that it used the ANSI C rand () function (but maybe you have more details about this and know that the key was generated by using rand (time()) ) ...
rand () is slow and there is no GPU-friendly implementation for hashcat of this.
"random" does not mean that a key with 2+ bytes that are equal, or even all bytes that are equal, could not exist... instead, if the key was generated randomly (cryptographically, truly random) there is no such limitation/filter.