Why is argon2i used?

[NicoHood]

Referring to: https://github.com/archlinux/archinstall/blob/master/archinstall/lib/luks.py#L73

I read that argon2id gives better security, so is there any reason against it?

[Torxed]

I'm not sure if this discussion #154 (Why use Argon2i over aes-xts-plain64?) answers this? I think it's a trade off to not sacrifice speed potential.

[NicoHood]

I was more asking of why argon2i not argon2id. That is not so clear to me still. I dont think we need too much configuration here, but a good default. To me it seems that id is better than just i, but I might be wrong with that assumption.

[Torxed]

I was more asking of why argon2i not argon2id. That is not so clear to me still. I dont think we need too much configuration here, but a good default. To me it seems that id is better than just i, but I might be wrong with that assumption.

Other than rumors about performance impact and never have tested it, there's no reason why not. Would be a welcome change if we can compare some benchmarks and test for stability.

[dylanmtaylor]

From Wikipedia,

The Internet draft recommends using Argon2id except when there are reasons to prefer one of the other two modes.

As such, +1 to switching it.

[qx-775]

The Arch Linux wiki however does point out to use "...Argon2i for key derivation" "... it is recommended to keep the default as is so as not to inadvertently decrease security."

Although argon2id is in most cases the preferred variant of the Argon2 family, the quoted RFC does indicate that:

Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation.
We can also see this reflected in this mailing list answer by cryptsetup maintainer Milan Broz:

You can use Argon2id though (combination of data dependent and independent processing). I prefer Argon2i for key derivation, but opinions differ here.
Therefore it is recommended to keep the default as is so as not to inadvertently decrease security.

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Choice_of_argon2_variant_for_PBKDF

Argon2i is the default. Should we not hold onto well tested defaults? Yes the wikipedia page says that argon2i is in theory more vulnerable to bruteforce attacks but has argon2id and its limitations been tested for security and performance?

Therefore maybe it's best to recommend a pasword length and strength during archinstall setup of X length containing at least 1 special symbol etc (maybe use NIST standard recommendation for passwords). Do you agree?

[dylanmtaylor]

The Arch Linux wiki however does point out to use "...Argon2i for key derivation" "... it is recommended to keep the default as is so as not to inadvertently decrease security."

Although argon2id is in most cases the preferred variant of the Argon2 family, the quoted RFC does indicate that:

Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation.
We can also see this reflected in this mailing list answer by cryptsetup maintainer Milan Broz:

You can use Argon2id though (combination of data dependent and independent processing). I prefer Argon2i for key derivation, but opinions differ here.
Therefore it is recommended to keep the default as is so as not to inadvertently decrease security.

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Choice_of_argon2_variant_for_PBKDF

Argon2i is the default. Should we not hold onto well tested defaults? Yes the wikipedia page says that argon2i is in theory more vulnerable to bruteforce attacks but has argon2id and its limitations been tested for security and performance?

Therefore maybe it's best to recommend a pasword length and strength during archinstall setup of X length containing at least 1 special symbol etc (maybe use NIST standard recommendation for passwords). Do you agree?

I am strongly against forcing anyone to have a minimum password quality. If they want to have a one letter password or something, we should not stop them. We do not want to push decisions onto the user, no matter how well intentioned.

[qx-775]

 am strongly against forcing anyone to have a minimum password quality. If they want to have a one letter password or something, we should not stop them. We do not want to push decisions onto the user, no matter how well intentioned.

I agree. That's why to recommend a minimal length on detection of low password length like most other installers (Calamares etc) do.

[Torxed]

I think the best way forward is to stick with the default, and add a --PBKDF=<method> in the future so that it's optionally configurable through a non-intrusive way for the general public. Most people should be satisfied with the default - which we'll adhere to for now. But at least enable the option to go with freaky configuration options via flags that override default. And document them in man archinstall. Would this be satisfactory?

Regarding password length, this is something that's near and dear to my heart. I don't mind opening up for a yellow notification saying "Password used is weak but can be changed in post installation". As keys are replaceable with LUKS2.

[qx-775]

Great ideas Torxed!