“These configuration settings provide an equal level of defense. The only difference is a trade off between CPU and RAM usage.”
This is for the scrypt section, where it says: “Like Argon2id, scrypt has three different parameters that can be configured: the minimum CPU/memory cost parameter (N), the blocksize (r) and the degree of parallelism (p). Use one of the following settings:”
In the examples, they change memory and parallelism, and they show that the lowest memory case with the highest parallelism is equal to the highest memory case with the least parallelism.
This is confusing because I thought increasing parallelism makes it easier to crack.
I know nothing about scrypt, but if I had to guess, each parallel thread in the scrypt algorithm requires its own allocation of memory, while in the Argon2id algorithm, the same memory allocation is worked on in parallel by each thread,
My reference for standards was to the OWASP recommendations. I did read the RFC but found my iPhone was 1.936GB short of the recommended 2GB. Note also that the RFC refers to a single iteration and sets as context, “is not tailored to your application or hardware”. Therefore I based my approach on Bitwarden’s upgraded parameters from OWASP.
In this part from OWASP:
That, as you say, is stated under scrypt where in relation to Argon2id they merely state that p is a settable parameter. I have seen nothing which suggests to me that p operates other than as already stated above: more, useable p shortens the time if the implementation is multi-threaded. Therefore, security is gained by a longer, stronger password, and by raising either or both of memory and iterations to the extent you and your CPU can agree on the consequent delay.