argon2ID parameter Threads must be fixed, cannot be based on num CPU

[glycerine]

Line 18 of https://github.com/PlakarKorp/plakar/blob/main/CRYPTOGRAPHY.md

says

KDF: ARGON2ID (with time=4, Memory=256M, Threads=NumCPU, SaltSize=16, KeyLen=32)

but unfortunately the NumCPU cannot be varied between user machines. You will get a different output if this varies, which will make decryption impossible.

You must use a fixed number here. I use Threads=1 here in my implementation, to make attacks harder (attackers do not get any benefit from the parallelism of their ASICs and GPUs in their cracking attempts).

[glycerine]

Also, cryptanalysis of the related argon2i showed it was vulnerable at time <=10, so I picked time=12 for good measure.

Reference: https://en.wikipedia.org/wiki/Argon2

The second attack shows that Argon2i can be computed by an algorithm which has complexity O(n7/4 log(n)) for all choices of parameters σ (space cost), τ (time cost), and thread-count such that n=σ∗τ.[8] The Argon2 authors claim that this attack is not efficient if Argon2i is used with three or more passes.[7] However, Joël Alwen and Jeremiah Blocki improved the attack and showed that in order for the attack to fail, Argon2i v1.3 needs more than 10 passes over memory.[5]

[poolpOrg]

Regarding the fixed Threads parameter, it was not varied between machines because it is stored in the KDF configuration and used to feed future derivations but you are right that using NumCPU is not a good idea as it means the default KDF parameters vary depending on which machine initialized the repository. A PR is pending to switch it to 1.

Regarding the other comment:

The attack exploits vulnerabilities in the data‐independent memory access pattern used by Argon2i. Argon2id, by contrast, uses a hybrid approach that combines both data‐independent and data‐dependent accesses, which largely mitigates the efficiency improvements that the attack achieves against Argon2i. This is why RFC9106 recommends using Argon2id over Argon2i.

We'll stick to what auditor suggested as default parameters but they will later be exposed so it is possible to configure them on a specific repository for more paranoid people :-)

This ticket will be closed when #505 goes in

[glycerine]

You no longer have "defense in depth" when you choose parameters that make one of the two legs of the hybrid 2id compromised. Not smart.

It is worth reviewing page 13 of

https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-13#section-4

and noting how much memory they are suggesting to use: 1GB, 4GB, 6GB with a smaller time param.

[poolpOrg]

For clarification, we asked our auditor to read this issue and provide feedback.

To quoting him:

t=4 for Argon2Id is generally largely sufficient and as for memory you need a value that will work for most platforms without inducing a self-DoS

Considering that our settings fall in-between the first and second recommended ones and that he's one of the people cited for helping review this RFC, we'll stick to his advice as he is our cryptography caution :-)

That being said, future releases will allow tuning parameters should people have different requirements.

PS: the audit will be committed to the repository and to our website on Monday.