/
limits.txt
83 lines (51 loc) · 2.63 KB
/
limits.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
##
## Maximum password lengths vary depending on kernel, hash type, and encoding
##
See https://hashcat.net/faq/lengths
##
## Generic hash modes only support salt lengths up to 256
##
This limitation on salt lengths only affects generic hash modes, such as md5(pass.salt).
Dedicated hash modes allow unlimited salt length support.
##
## File and folder names including UTF-16 characters are not supported
##
UTF-16 is mostly seen on Windows. UTF-8 (as mostly used on Linux and macOS) are fine.
Important: That does not mean UTF-16 file content, which is fully supported.
It only means the filename itself.
##
## Hashing algorithms that internally use UTF-16 characters could in special cases lead to false negatives
##
The UTF-16 conversion implementation used within the kernel code is very elementary and for performance
reasons does not respect all complicated encoding rules required to correctly convert, for instance, ASCII
or UTF-8 to UTF-16LE (or UTF-16BE).
The implementation most likely fails with multi-byte characters, because we basically add a zero byte every
second byte within the kernel conversion code.
##
## The use of --keep-guessing eventually skips reporting duplicate passwords
##
This does not mean that valid passwords are skipped; they are always reported.
Only if you hit the same password twice for the same hash the password may be shown only once.
If --keep-guessing is not used, this can not occur.
This limitation cannot be fixed, because it would require too much device (GPU/CPU) memory.
If we wanted to report back all possible password candidates executed in a single kernel invocation, it would require this much memory:
Number-of-MCU * Max-threads-per-device * Max-accel * Max-inner-loops * sizeof (plain_t)
For example, on a Vega64: 64 * 512 * 1024 * 1024 * 20 = 687,194,767,360 bytes
##
## Hashcat GPU memory usage may be limited by maximum allocation sizes of OpenCL drivers
##
Most hashcat hash modes only use a single OpenCL allocation.
The size of this allocation is limited by GPU drivers / OpenCL runtimes.
Only a few modes (like scrypt) make more than one allocation.
##
## The maximum number of functions per rule is limited to 31
##
This makes the size of one rule 128 byte.
On the other hand, there is a 25% OpenCL single allocation memory limit.
A typical GPU of today has 8GB = 2GB/128 = 16M rules max
If hashcat supported more functions per rule, it would be limited to fewer rules.
This is a trade-off game.
##
## Position identifiers in rules are limited to 36
##
The upper limit of maximum 36 positions for various rule functions (0-9, A-Z) was a design decision by the original authors of the rule engine.