Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The LUKS2 source code mentions there is an attack on Argon2 which they prevent by setting rounds to 2 or 4 iirc. Not sure what that's about though, would need to look it up again but perhaps heed the recommended settings to avoid such pitfalls

As for parallelism=1, why would you do that? My understanding is that you want it to a point where it'll saturate your memory bus because then you're getting the most out of your system -> making it the hardest for the attacker. (Pretty sure this takes more than one thread on a modern system because I've tested that argon2id with the same number of rounds and memory gets faster with more threads.) Beyond that, increasing memory usage is good because that dominates the die space of an ASIC which in turn dominates the cost, if I remember and understood the argon2 paper correctly. The repetitions value is the last thing to touch, namely when you've run out of threads and usable RAM (such as when it gets into DoS territory)

(I focus on argon2 because that's what I've read up on. Scrypt is also a good option but I'm not sure the same advice applies because it has this TMTO attack. The underlying concepts will be the same of course, but tweaking one parameter before another may play into the attacker's hand.)



No. The parallelism is an upper bound, higher reduces security. If you're running a server for multiple clients each client should only get one thread for argon2 anyway, more won't help your overall throughput.


I'm not understanding the why behind that claim


It's been a while, I thought it was something to do with the blocks but it probably depends on what the exact state of the art is for cracking at this point.

Don't put it any higher than 4, that's for sure.

In theory a parallelism on 1 should make it so the information required to do the next step has to be computed linearly (think of the dependency graph, it should look like a line instead of diverging then converging) but it's possible that either never worked or got cracked.


PBKDF2 makes it harder by using more ALU related functions to calculate the key. The problem is ALU's are rather easy to add to a chip, which means it is relatively easy to increase parallelism. ALU parallelism is I'm guessing what you are thinking of.

The others target other constraints, with varying degrees of success. Scrypt for example targets the connection between the CPU chip and DRAM. It doesn't use a lot of CPU time, but rather jumps in a very random way over a whole pile of memory. So adding ALU's doesn't help you crack scrypt. You have to increase memory bandwidth. How fast you can access memory is effectively limited by the numbers of pins you can put on a die, and the number of pins is far harder to increase that the number of ALU's.

So the answer is yes parallelism always helps, but if you chose the things that constrains you to stuff that is hard to add (like pins) adding that parallelism is hard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: