09-03-2017, 07:33 PM
As already mentioned above, the hash algorithm itself determines where/how the password candidates are generated for mask attacks (-a 3).
The hashcat source code distinguishes between ATTACK_EXEC_INSIDE_KERNEL and ATTACK_EXEC_OUTSIDE_KERNEL.
You can also just look at the OpenCL/ folder and see which hash types use a *_a3.cl kernel and which do not (the kernel file name is in case of ATTACK_EXEC_INSIDE_KERNEL m[hash_type]_a3.cl or in case of ATTACK_EXEC_OUTSIDE_KERNEL m[hash_type].cl).
The main reasons for this differences are that, as already mentioned above, some hashing algorithms are themself much more demanding/slower/use more instructions/iterations and therefore here the core computation is the main bottleneck (and not the password candidate generation/read/transfer etc) and the second reason is that hashcat needs to keep the runtime of a single kernel run low to avoid kernel timeouts (default operating systems settings and driver settings set a very low timeout for kernel runs and if this time is exceeded you will get a warning that your system is "unresponsible" - and of course it could also be the case that it really gets unresponsible with high workload settings - ... furthermore the user also wants that the status display updates regularily and frequently such that she can see the progress).
The hashcat source code distinguishes between ATTACK_EXEC_INSIDE_KERNEL and ATTACK_EXEC_OUTSIDE_KERNEL.
You can also just look at the OpenCL/ folder and see which hash types use a *_a3.cl kernel and which do not (the kernel file name is in case of ATTACK_EXEC_INSIDE_KERNEL m[hash_type]_a3.cl or in case of ATTACK_EXEC_OUTSIDE_KERNEL m[hash_type].cl).
The main reasons for this differences are that, as already mentioned above, some hashing algorithms are themself much more demanding/slower/use more instructions/iterations and therefore here the core computation is the main bottleneck (and not the password candidate generation/read/transfer etc) and the second reason is that hashcat needs to keep the runtime of a single kernel run low to avoid kernel timeouts (default operating systems settings and driver settings set a very low timeout for kernel runs and if this time is exceeded you will get a warning that your system is "unresponsible" - and of course it could also be the case that it really gets unresponsible with high workload settings - ... furthermore the user also wants that the status display updates regularily and frequently such that she can see the progress).