mirror of
https://github.com/hashcat/hashcat.git
synced 2024-10-31 20:48:57 +00:00
90 lines
3.2 KiB
Plaintext
90 lines
3.2 KiB
Plaintext
##
|
|
## 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
|
|
##
|
|
|
|
This applies to optimized kernels (-O) only:
|
|
|
|
The UTF-16 conversion implementation used within the kernel code is optimized for performance. For that
|
|
reason, hashcat 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.
|
|
|
|
Since hashcat v6.2.1 there is true UTF-16 support for pure kernels. UTF-16 is fully supported.
|
|
|
|
There is an exception for mask attacks combined with compute devices that require vector data-types
|
|
to achieve full performance. For example a modern CPU. For these devices, the recommendation is to use a
|
|
combination of mask processor piped to hashcat. For modern GPUs it works as expected.
|
|
|
|
##
|
|
## 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 per device:
|
|
|
|
Number-of-MCU * Max-threads * Max-accel * Max-inner-loops * sizeof (plain_t)
|
|
|
|
For example, on a Vega64: 64 * 1024 * 1024 * 1024 * 20 = 1,374,389,534,720 bytes = 1280 GB VRAM
|
|
|
|
##
|
|
## Hashcat GPU memory usage may be limited by maximum memory allocation sizes of OpenCL drivers
|
|
##
|
|
|
|
Most hashcat memory allocations are supposed to remain inside the same memory area.
|
|
|
|
The maximum size of a memory allocation is limited by GPU drivers / OpenCL runtimes.
|
|
|
|
Only a few modes (like scrypt) have special workarounds to make use of 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.
|
|
|