Optimal RAM size for the fastest Ethereum Scrypt v3 cracking

[servercat]

Hi everyone!

Help me to evaluate RAM I needed for getting the most out of the Intel i9-10900KF, plz.
It has 10 cores, 20 threads.

Code:

hashcat -I
    …
    Processor(s)...: 20

So for $ethereum$s*262144*1*8*3436383737333838313035343736303637353530323430373235343034363130*8b58d9d15f579faba1cd13dd372faeb51718e7f70735de96f0bcb2ef4fb90278*8de566b919e6825a65746e266226316c1add8d8c3d15f54640902437bcffc8c3

  262144 (n - CPU/Memory cost parameter)
* 1 (r - blocksize for each mixing loop)
* 8 (p - parallelization factor)
* 128 (scrypt size)
= 268435456 Bytes
= 256 MB
* 20 (i9 Total CPU threads)
* ? what other factors should be considered here ?

[Snoopy]

how about starting an attack on the example hash (you could edit the params to match your params) and take a look, hahscat will tell you how much ram is needed

[servercat]

Code:

hashcat.exe -m15700 -a3 -D1 --status "$ethereum$s*262144*1*8*3436383737333838313035343736303637353530323430373235343034363130*8b58d9d15f579faba1cd13dd372faeb51718e7f70735de96f0bcb2ef4fb90278*8de566b919e6825a65746e266226316c1add8d8c3d15f54640902437bcffc8c3" ?a?a?a?a
hashcat (v6.2.5) starting

You have enabled --force to bypass dangerous warnings and errors!
This can hide serious problems and should only be done when debugging.
Do not report hashcat issues encountered when using --force.

CUDA API (CUDA 11.5)
====================
* Device #1: NVIDIA GeForce GTX 1650, skipped

OpenCL API (OpenCL 3.0 CUDA 11.5.125) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #2: NVIDIA GeForce GTX 1650, skipped

OpenCL API (OpenCL 2.1 WINDOWS) - Platform #2 [Intel(R) Corporation]
====================================================================
* Device #3: Intel(R) Core(TM) i9-10900KF CPU @ 3.70GHz, 8116/16297 MB (2037 MB allocatable), 20MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 0 MB   < ??

[Snoopy]

well funny, tells me the same

taking a quick look, hashcat consumes around 2026 MB of RAM for this attack

jfyi, bruteforcing ethereum wallets, well dont try it, first of all i think most wallets have a minimum password length of 8?, even if not, scrypt is soooooooooooooooooooooooooo slow, without a good clue about the pass or some very specific lists for that specific user you will never be able to bruteforce a password

fast test with a dual xeon 2*12 log *2 virt = 48 threads ?a 6 times and 256 GB RAM > over 10 years

[servercat]

Аccording to your advice I took the example hash, so it's password is known and (I think) the mask and time left doesn't matter yet.

You are right, scrypt is terribly slow.

But, the questions are:

· How much RAM use hashcat for the Ethereum Wallet SCRYPT (15700) hash mode?

· Does it de facto use all available memory from your 256 GB's, although according to your assumption 96 GB (2026 MB (?) per thread * 48 threads) would be enough?
  How many threads does hashcat spawn on your system?
  In my case 27 (20 of them are engaged in brute force)

It is noticed, that increasing the memory increases the hash rate, but
· what is the optimal RAM volume (in relation to the known number of threads) for the fastest cracking?

[Snoopy]

well my 2 GB mentioned above are with mode 15700

as long as i didnt tell hashcat to stick to a specific count of processors it will always use all the power i have

as far as i can see from my setup there is no difference in more RAM, if hashcat would need more ram for this attack it would have consumed it but it sticks with 2 GB for the bruteforce

if i tell hashcat to use a 1 GB wordlist + 1 rule , it consumes around 3,3 GB so yeah it seems to me, basic 2gb for the scrypt plus 1 gb for the dict, the rest well dunno, some needed overhead