What is the role played by cache misses in memory-hard password hashing?

Question

I experiment with argon2 and build a web application. In browser, I use one threaded hashing with not too much memory. I want to protect my short length input data from parallel brute-force attack.

I understand, using large memory (1GB or greater) prevent parallelism, because of the cost. I would like to support mobile and older browsers, so I use 16MB or 32MB memory maximum.

I thought argon2 indexing function generate large amount of cache miss, while randomly access the shared memory and a cores waiting a lot. Consequently parallelism increase the cache miss count and slowing down the hashing. I was benchmarked in parallel, but it is not affected, parallelism worked.

Is it because my benchmarks wrong or is not generate a lot cache misses I thought or cache misses not affects like the processing?

Cache misses wrong for memory-hardness, because the waiting cores might compute a missing memory faster then the waiting time, aka time-memory tradeoff?

edit1 What is the relationship between used memory and memory bandwidth and speed?

Answer 1

I understand, using large memory (1GB or greater) prevent parallelism, because of the cost. I would like to support mobile and older browsers, so I use 16MB or 32MB memory maximum.

This is true, but 32mb memory is fairly safely OK for most applications.

Is it because my benchmarks wrong or is not generate a lot cache misses I thought or cache misses not affects like the processing?

Problem of password cracking isn't mere 16 threads that a CPU can pull off. CPU is fairly complex thing and even if it can't cache whatever you throw at it, it has multiple channels of high-speed ram with capacities reaching into terabytes for powerful servers.

Problem starts when everyone has thousands of processors in their computer. This is case right now with GPUs. GPUs make use of massive parallelism. This makes some tradeoffs, for example every thread has tiny amount of memory and no cache. Common GPU programming technique require that data to be accessed next is fetched earlier and saved in that reduced space. This obviously can't happen with 32mb table, which is further limited by huge performance cost of accessing global GPU memory (and you have thousands on threads all accessing some random informations). And you don't even have enough memory in GPU to run 1000 threads at once.

Argon also tries to combat all kind of premade chips to break it quickly by using a lot of memory quickly: your can't just invest into a lot of quickly-hashing chips because they will need megabytes or more per one chip.

So if you were running your benchmarks with CPUs this is expected that it will run this algorithm fairly well. After all argon2 was made so that it runs efficiently on multiprocessor CPU, but not on GPU or ASIC.