You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Question] Why use Argon2i over aes-xts-plain64? #144
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!
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 :)
Activity
Torxed commentedon Apr 2, 2021
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-plain64by default as it's cipher mechanism, and it's just the PBKDF that isargoni2iin our case. You should be able to verify this with:cryptsetup luksDump /dev/yourPartition2to 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 commentedon Apr 2, 2021
@Torxed already explained the difference between --cipher and --pbkdf, cyptsetup currently supports 3 different pbkdfs:
The current defaults in Arch Linux at the time of writing: