@ -386,189 +386,13 @@ GeForce_GTX_TITAN 3 9900 2 A
DEVICE_TYPE_CPU * 3200 1 N A
##
## SCRYPT
## SCRYPT: Tunings for SCRYPT based hash-modes can be found inside the plugin source
## See function module_extra_tuningdb_block()
##
DEVICE_TYPE_CPU * 8900 1 N A
DEVICE_TYPE_CPU * 9300 1 N A
DEVICE_TYPE_CPU * 15700 1 N A
DEVICE_TYPE_CPU * 22700 1 N A
DEVICE_TYPE_GPU * 8900 1 N A
DEVICE_TYPE_GPU * 9300 1 N A
DEVICE_TYPE_GPU * 15700 1 1 A
DEVICE_TYPE_GPU * 22700 1 N A
##
## CryptoAPI
##
DEVICE_TYPE_CPU * 14500 1 A A
DEVICE_TYPE_GPU * 14500 1 A A
## Here's an example of how to manually tune SCRYPT algorithm kernels for your hardware.
## Manually tuning the GPU will yield increased performance. There is typically no noticeable change to CPU performance.
##
## First, you need to know the parameters of your SCRYPT hash: N, r and p.
##
## The reference SCRYPT parameter values are N=14, r=8 and p=1, but these will likely not match the parameters used by real-world applications.
## For reference, the N value represents an exponent (2^N, which we calculate by bit shifting 1 left by N bits).
## Hashcat expects this N value in decimal format: 1 << 14 = 16384
##
## Now that you have the 3 configuration items in decimal format, multiply them by 128 (underlaying crypto primitive block size).
## For example: 128 * 16384 * 8 * 1 = 16777216 = 16MB
## This is the amount of memory required for the GPU to compute the hash of one password candidate.
##
## Hashcat computes multiple password candidates in parallel - this is what allows for full utilization of the device.
## The number of password candidates that Hashcat can run in parallel is VRAM limited and depends on:
##
## 1. Compute devices' native compute units
## 2. Compute devices' native thread count
## 3. Artificial multiplier (--kernel-accel aka -n)
##
## In order to find these values:
##
## 1. On startup Hashcat will show: * Device #1: GeForce GTX 980, 3963/4043 MB, 16MCU. The 16 MCU is the number of compute units on that device.
## 2. Native thread counts are fixed values: CPU=1, GPU-Intel=8, GPU-AMD=64 (wavefronts), GPU-NVIDIA=32 (warps)
##
## Now multiply them together. For my GTX980: 16 * 32 * 16777216 = 8589934592 = 8GB
##
## If we want to actually make use of all computing resources, this GPU would require 8GB of GPU RAM.
## However, it doesn't have that:
##
## Device #1: GeForce GTX 980, 3963/4043 MB, 16MCU. We only have 4043 MB (4GB minus some overhead from the OS).
##
## How do we deal with this? This is where SCRYPT TMTO(time-memory trde off) kicks in. The SCRYPT algorithm is designed in such a way that we
## can pre-compute that 16MB buffer from a self-choosen offset. Details on how this actually works are not important for this process.
##
## What's relevant to us is that we can halve the buffer size, but we pay with twice the computation time.
## We can repeat this as often as we want. That's why it's a trade-off.
##
## This mechanic can be manually set using --scrypt-tmto on the commandline, but this is not the best way.
##
## Back to our problem. We need 8GB of memory but have only ~4GB.
## It's not a full 4GB. The OS needs some of it and Hashcat needs some of it to store password candidates and other things.
## If you run a headless server it should be safe to subtract a fixed value of 200MB from whatever you have in your GPU.
##
## So lets divide our required memory(8GB) by 2 until it fits in our VRAM - 200MB.
##
## (8GB >> 0) = 8GB < 3.8GB = No, Does not fit
## (8GB >> 1) = 4GB < 3.8GB = No, Does not fit
## (8GB >> 2) = 2GB < 3.8GB = Yes!
##
## This process is automated in Hashcat, but it is important to understand what's happening here.
## Because of the light overhead from the OS and Hashcat, we pay a very high price.
## Even though it is just 200MB, it forces us to increase the TMTO by another step.
## In terms of speed, the speed is now only 1/4 of what we could archieve on that same GPU if it had only 8.2GB ram.
## But now we end up in a situation that we waste 1.8GB RAM which costs us ((1.8GB/16MB)>>1) candidates/second.
##
## This is where manual tuning can come into play.
## If we know that the resources we need are close to what we have (in this case 3.8GB <-> 4.0GB)
## We could decide to throw away some of our compute units so that we will no longer need 4.0GB but only 3.8GB.
## Therefore, we do not need to increase the TMTO by another step to fit in VRAM.
##
## If we cut down our 16 MCU to only 15 MCU or 14 MCU using --kernel-accel(-n), we end up with:
##
## 16 * 32 * 16777216 = 8589934592 / 2 = 4294967296 = 4.00GB < 3.80GB = Nope, next
## 15 * 32 * 16777216 = 8053063680 / 2 = 4026531840 = 3.84GB < 3.80GB = Nope, next
## 14 * 32 * 16777216 = 7516192768 / 2 = 3758096384 = 3.58GB < 3.80GB = Yes!
##
## So we can throw away 2/16 compute units, but save half of the computation trade-off on the rest of the compute device.
## On my GTX980, this improves the performance from 163 H/s to 201 H/s.
## You don't need to control --scrypt-tmto manually because now that the multiplier (-n) is smaller than the native value
## Hashcat will automatically realize it can decrease the TMTO by one.
##
## At this point, you found the optimal base value for your compute device. In this case: 14.
##
## Depending on our hardware, especially hardware with very slow memory access like a GPU
## there's a good chance that it's cheaper (faster) to compute an extra step on the GPU register.
## So if we increase the TMTO again by one, this gives an extra speed boost.
##
## On my GTX980, this improves the performance from 201 H/s to 255 H/s.
## Again, there's no need to control this with --scrypt-tmto. Hashcat will realize it has to increase the TMTO again.
##
## All together, you can control all of this by using the -n parameter in the command line.
## This is not ideal in a production environment because you must use the --force flag.
## The best way to set this is by using this Hashcat.hctune file to store it. This avoids the need to bypass any warnings.
##
## Find the ideal -n value, then store it here along with the proper compute device name.
## Formatting guidelines are availabe at the top of this document.
##
## -------------------------------------------------
##
## You can also ignore all theoretical derivations and semi-automate the process in the real scenario (I prefer this approach):
##
## 1. For example, to find the value for 8900, first create a valid hash for 8900 as follows:
##
## $ ./hashcat --example-hashes -m 8900 | grep Example.Hash | grep -v Format | cut -b 25- > tmp.hash.8900
##
## 2. Now let it iterate through all -n values to a certain point. In this case, I'm using 200, but in general it's a value that is at least twice that of the multiprocessor. If you don't mind you can just leave it as it is, it just runs a little longer.
##
## $ export i=1; while [ $i -ne 201 ]; do echo $i; ./hashcat --quiet tmp.hash.8900 --keep-guessing --self-test-disable --markov-disable --restore-disable --outfile-autohex-disable --wordlist-autohex-disable --potfile-disable --logfile-disable --hwmon-disable --status --status-timer 1 --runtime 28 --machine-readable --optimized-kernel-enable --workload-profile 3 --hash-type 8900 --attack-mode 3 ?b?b?b?b?b?b?b --backend-devices 1 --force -n $i; i=$(($i+1)); done | tee x
##
## 3. Determine the highest measured H/s speed. But don't just use the highest value. Instead, use the number that seems most stable, usually at the beginning.
##
## $ grep "$(printf 'STATUS\t3')" x | cut -f4 -d$'\t' | sort -n | tail
##
## 4. To match the speed you have chosen to the correct value in the "x" file, simply search for it in it. Then go up a little on the block where you found him. The value -n is the single value that begins before the block start. If you have multiple blocks at the same speed, choose the lowest value for -n
##
## 4GB
GeForce_GTX_980 * 8900 1 29 A
GeForce_GTX_980 * 9300 1 128 A
GeForce_GTX_980 * 15700 1 24 A
GeForce_GTX_980 * 22700 1 29 A
## 8GB
GeForce_GTX_1080 * 8900 1 15 A
GeForce_GTX_1080 * 9300 1 256 A
GeForce_GTX_1080 * 15700 1 28 A
GeForce_GTX_1080 * 22700 1 15 A
## 11GB
GeForce_RTX_2080_Ti * 8900 1 68 A
GeForce_RTX_2080_Ti * 9300 1 528 A
GeForce_RTX_2080_Ti * 15700 1 68 A
GeForce_RTX_2080_Ti * 22700 1 68 A
## 8GB
GeForce_RTX_3060_Ti * 8900 1 51 A
GeForce_RTX_3060_Ti * 9300 1 256 A
GeForce_RTX_3060_Ti * 15700 1 11 A
GeForce_RTX_3060_Ti * 22700 1 51 A
## 8GB
GeForce_RTX_3070 * 8900 1 46 A
GeForce_RTX_3070 * 9300 1 368 A
GeForce_RTX_3070 * 15700 1 22 A
GeForce_RTX_3070 * 22700 1 46 A
## 24GB
GeForce_RTX_3090 * 8900 1 82 A
GeForce_RTX_3090 * 9300 1 984 A
GeForce_RTX_3090 * 15700 1 82 A
GeForce_RTX_3090 * 22700 1 82 A
## 4GB
ALIAS_AMD_RX480 * 8900 1 15 A
ALIAS_AMD_RX480 * 9300 1 232 A
ALIAS_AMD_RX480 * 15700 1 58 A
ALIAS_AMD_RX480 * 22700 1 15 A
## 8GB
ALIAS_AMD_Vega64 * 8900 1 31 A
ALIAS_AMD_Vega64 * 9300 1 440 A
ALIAS_AMD_Vega64 * 15700 1 53 A
ALIAS_AMD_Vega64 * 22700 1 31 A
## 32GB
ALIAS_AMD_MI100 * 8900 1 79 A
ALIAS_AMD_MI100 * 9300 1 1000 A
ALIAS_AMD_MI100 * 15700 1 120 A
ALIAS_AMD_MI100 * 22700 1 79 A
## 16GB
ALIAS_AMD_RX6900XT * 8900 1 59 A
ALIAS_AMD_RX6900XT * 9300 1 720 A
ALIAS_AMD_RX6900XT * 15700 1 56 A
ALIAS_AMD_RX6900XT * 22700 1 59 A
Jens Steube
3 years ago