Why use Argon2i over aes-xts-plain64?

[qx-775]

Problem

As a user I am interested in protecting my arch linux install with disk encryption. Looking at the luks python file i can see you are using argon2i as cypher while most other distribution use the well tested AES. What is the reason for choosing argon2i?
I am interested in security, but not a professional so I am just curious to know why.

Potential vulnerability?

Looking at wikipedia
Wikipedia page says: "there are two published attacks on the Argon2i function."

Request

This worries me. Is it possible to use argon2id, which protects against side channel attacks and also protects against GPU based attacks? Also I believe from standard cryptsetup benchmark tests aes-xts-plain64 has the highest read and write score which is important for daily usage. Therefore should we use aes instead? Also because it's standard in most other distro's.

Conclusion

Could you consider changing the luks cypher on the reason described above? Or at least clarify why you used argon? Thank you!

[Torxed]

I don't mind considering changing the default parameters, I'm also looking in to how these arguments could be made available via parameters some how (without adding complexity for "most users").

But to answer your argument:
The reason behind this was that at the time of writing this part of code, way back. LUKS2 that "had just come out" had argoni2i as the default algorithm and was resistant to side channel attacks. However, it was susceptible to GPU attacks.

Regarding AES, without checking I'm going to make a bold claim that might backfire, in which case, keep it civil and just mention that this is wrong :P But LUKS2 uses aes-xts-plain64 by default as it's cipher mechanism, and it's just the PBKDF that is argoni2i in our case. You should be able to verify this with: cryptsetup luksDump /dev/yourPartition2 to verify.

Reading that wiki article, one of those attacks were on the old implementation of Argoni2 and not the latest reference implementation. And I think it's more important to have a good hash size in this case and a good iteration count, and trust the default implementations.

tl;dr: I'm looking in to ways of enabling more complicated and dynamic setups of generally the entire partitioning setup (this includes encryption). But you'll have to hang tight for the next release :)

Edit: found a decent write-up on what I was rambling on about: https://security.stackexchange.com/questions/229553/what-is-the-digests-section-in-cryptsetup

[kpcyrd]

@Torxed already explained the difference between --cipher and --pbkdf, cyptsetup currently supports 3 different pbkdfs:

• pbkdf2
• argon2i
• argon2id (this one would be the hardest to bruteforce)

The current defaults in Arch Linux at the time of writing:

% cryptsetup --help
[...]
Default compiled-in metadata format is LUKS2 (for luksFormat action).

Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2i
        Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4

Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
        LUKS: Default keysize with XTS mode (two internal keys) will be doubled.