hashcat/docs/limits.txt

##
## 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.