d9918d7e44
=====================================
This patch modifies the existing Argon2 plugin, which was initially
designed to work only with CUDA. Supporting OpenCL and HIP required
broader architectural changes.
1. The tmps[] structure no longer holds the "large buffer". This
buffer stored the scratch areas for all password candidates in one
chunk. But we do not need to hold scratch areas for all candidates
simultaneously. All we need to do is hold chunks large enough
per password.
To simplify logic, the buffer is not divided by password count, but
divided by four, which fits within the "1/4 global memory" limit on
some OpenCL runtimes.
Hashcat already had logic to support this, but the buffer needed to be
moved to a different buffer type. It has now been relocated from the
"tmp buffer" to the "extra tmp buffer", following the same strategy
used in newer SCRYPT plugins.
This improves handling across several subcomponents:
- Hashcat backend divides into four asymmetric buffers, hence the
name "4-buffer strategy"
- If the candidate count isn't divisible by 4, leftover candidates are
assigned to the first (and possibly second and third) buffer
- No code in the plugin is required, as this was designed for exactly
such cases where future algorithms require a lot of memory
- Plugin was rewritten to report the size needed in
module_extra_tmp_size(), which triggers the "4-buffer" strategy
- The split is not even, but each part is large enough to hold
a multiple of a full scratch buffer for a password
- The kernel code in m34000_init/loop/comp now uses a code block
that finds its buffer by doing "group_id % 4"
- Prevents the need to over-allocate memory to avoid OOB access
- The original "tmps buffer" now holds a small dummy state buffer
2. Replaced warp shuffle instruction
The instruction __shfl_sync() is not available in runtimes
other than CUDA. Some have alternatives, some do not.
To prevent branching per backend runtime, the new general macro
hc__shfl_sync() replaces all calls to __shfl_sync().
This allows us to implement runtime-specific solutions and
take effect at compile time to prevent regressions.
- CUDA:
We simply map to the original __shfl_sync()
- HIP:
We map to shfl(), a built-in intrinsic. This instruction doesn't
support masks like __shfl_sync() does, but masks are not needed
in Argon2 anyway. It requires an additional parameter, the wavefront
size. This is natively 64, but we hardcode this to 32 so it aligns
with NVIDIA's warp size.
- OpenCL:
- AMD: We have access to the instruction __builtin_amdgcn_ds_bpermute().
This instruction only supports 32-bit integers, requiring us to
pack and unpack the 64-bit values manually
- NVIDIA: We use inline assembly with "shfl.sync.idx.b32". Same as
with AMD, we need to pack and unpack 32-bit integers. The 64-bit
support in CUDA is just overloaded and internally does the same thing.
- Others: We use a shared memory pool and combine it with a barrier.
This LOCAL_VK pool must be sized at compile time and transported to
the Argon2 code in "inc_hash_argon2.cl". This required changing all
function declarations that use shuffles slightly.
Unlock full threading for init and comp kernels
===============================================
This is implemented using a new flag:
OPTS_TYPE_THREAD_MULTI_DISABLE
Behavior is similar to:
OPTS_TYPE_MP_MULTI_DISABLE
It simply disables the multiplier normally applied to password batch size.
But attention, this change completely unbinds this effect from the
real threads spawned on the compute device. If the thread count is not
set to 1 in the plugin, it will start autotuning it.
In the case of Argon2, we hard-code it to 32 instead, which also changes
how "warp size" was used in the original implementation, and which is not
compatible with HIP and/or OpenCL. However, we need to maintain this thread
size to utilize warp shuffle and its alternatives in other runtimes.
Benefits:
- Enables full threading for init and comp kernels (1667 H/s to 1722 H/s)
- Allows future algorithms to enable parallel processing of single
password candidates, if supported
Plugin changes:
- Removed the "hack" where thread count = 1 disabled the multiplier
- Removed per-device warp count detection code and struct changes
- Removed warp handling and "num_elements / thread_count" division in
the run_kernel() function
Simplified autotune logic for Argon2
====================================
The goal is to calculate the maximum number of password candidates that
can run in parallel, constrained only by device memory.
- Removed all code related to Argon2 from autotune
- Implemented in "module_extra_tuningdb_block()" (like SCRYPT)
- We create a tuningdb entry at runtime!
- Still allows override via tuningdb or CLI
- Considers register spilling (read at startup)
- Prevents global-to-host memory swap performance issues
Add Argon2I and ArgonD support
==============================
The kernel prepared from NFI already had support for the different Argon
types. No change was needed.
To support the other Argon2 types, the tokenizer had to be improved to
support a variety of different signatures in the same hash-mode.
Bugfixes
========
- Fixed missing entries in "switch_buffer_by_offset_8x4_le_S()"
- Fixed benchmark hash misdetection for scrypt. This was due to
outdated logic used in scrypt to detect whether the plugin was
called from a benchmark session or a regular one
- Fixed a bug in "module_hash_encode()" where Base64 padding '=' was
retained
- Fixed missing "GLOBAL_AS" / "PRIVATE_AS" casts for OpenCL
- Fixed compiler warnings (e.g., "index_u32x4()", "get_group_id()")
by adding return values
- Fixed a bug in token.len_max[6], which was allowing decoding
of a 256-byte data into a 16-byte buffer (digest)
Other improvements
==================
- Added unit test module for automated testing
- Added support to the tokenizer to allow multiple signatures.
Leave out TOKEN_ATTR_FIXED_LENGTH to enable this in your plugins
- Updated "hc_umulhi()", also exists for HIP
- Renamed "gid" to "bid" when using "get_group_id()" for clarity
- Removed "#ifdef IS_CUDA" as all backends are now supported
- Removed deprecated "OPTS_TYPE_MAXIMUM_ACCEL" attribute
Performance note
================
For testing, I used the self-test hash configured according to the
RFC 9106 recommendation: m=65536, t=3, p=1.
In my benchmarks, the AMD RX 7900 XTX achieved 1401 H/s using the same
hash that was used to test NVIDIA's RTX 4090. The RTX 4090 reached
1722 H/s, making it faster in absolute terms. However, at the time of
writing, it is more than three times as expensive as the 7900 XTX.
It's also worth noting that an older NVIDIA GTX 1080 Ti still reached
565 H/s with the same test vector, and may be found at significantly
lower cost.
Across all tested Argon2 configurations, the performance gap between
the RX 7900 XTX and the RTX 4090 remained proportionally consistent,
indicating a clear linear scaling relationship between the two GPUs.
|
||
|---|---|---|
| .github | ||
| bridges | ||
| charsets | ||
| deps | ||
| docker | ||
| docs | ||
| extra/tab_completion | ||
| include | ||
| layouts | ||
| masks | ||
| modules | ||
| obj | ||
| OpenCL | ||
| Python | ||
| rules | ||
| src | ||
| tools | ||
| tunings | ||
| .appveyor.yml.old | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| BUILD_CYGWIN.md | ||
| BUILD_Docker.md | ||
| BUILD_macOS.md | ||
| BUILD_MSYS2.md | ||
| BUILD_WSL.md | ||
| BUILD.md | ||
| example0.cmd | ||
| example0.hash | ||
| example0.sh | ||
| example400.cmd | ||
| example400.hash | ||
| example400.sh | ||
| example500.cmd | ||
| example500.hash | ||
| example500.sh | ||
| example.dict | ||
| hashcat.hcstat2 | ||
| Makefile | ||
| README.md | ||
hashcat
hashcat is the world's fastest and most advanced password recovery utility, supporting five unique modes of attack for over 300 highly-optimized hashing algorithms. hashcat currently supports CPUs, GPUs, and other hardware accelerators on Linux, Windows, and macOS, and has facilities to help enable distributed password cracking.
License
hashcat is licensed under the MIT license. Refer to docs/license.txt for more information.
Installation
Download the latest release and unpack it in the desired location. Please remember to use 7z x when unpacking the archive from the command line to ensure full file paths remain intact.
Usage/Help
Please refer to the Hashcat Wiki and the output of --help for usage information and general help. A list of frequently asked questions may also be found here. The Hashcat Forum also contains a plethora of information. If you still think you need help by a real human come to Discord.
Building
Refer to BUILD.md for instructions on how to build hashcat from source.
Tests:
| Travis | Coverity | GitHub Actions |
|---|---|---|
 |
 |
 |
Contributing
Contributions are welcome and encouraged, provided your code is of sufficient quality. Before submitting a pull request, please ensure your code adheres to the following requirements:
- Licensed under MIT license, or dedicated to the public domain (BSD, GPL, etc. code is incompatible)
- Adheres to gnu99 standard
- Compiles cleanly with no warnings when compiled with
-W -Wall -std=gnu99 - Uses Allman-style code blocks & indentation
- Uses 2-spaces as the indentation or a tab if it's required (for example: Makefiles)
- Uses lower-case function and variable names
- Avoids the use of
!and uses positive conditionals wherever possible (e.g.,if (foo == 0)instead ofif (!foo), andif (foo)instead ofif (foo != 0)) - Use code like array[index + 0] if you also need to do array[index + 1], to keep it aligned
You can use GNU Indent to help assist you with the style requirements:
indent -st -bad -bap -sc -bl -bli0 -ncdw -nce -cli0 -cbi0 -pcs -cs -npsl -bs -nbc -bls -blf -lp -i2 -ts2 -nut -l1024 -nbbo -fca -lc1024 -fc1
Your pull request should fully describe the functionality you are adding/removing or the problem you are solving. Regardless of whether your patch modifies one line or one thousand lines, you must describe what has prompted and/or motivated the change.
Solve only one problem in each pull request. If you're fixing a bug and adding a new feature, you need to make two separate pull requests. If you're fixing three bugs, you need to make three separate pull requests. If you're adding four new features, you need to make four separate pull requests. So on, and so forth.
If your patch fixes a bug, please be sure there is an issue open for the bug before submitting a pull request. If your patch aims to improve performance or optimize an algorithm, be sure to quantify your optimizations and document the trade-offs, and back up your claims with benchmarks and metrics.
In order to maintain the quality and integrity of the hashcat source tree, all pull requests must be reviewed and signed off by at least two board members before being merged. The project lead has the ultimate authority in deciding whether to accept or reject a pull request. Do not be discouraged if your pull request is rejected!