##

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

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