As of right now the time of writing the default LUKS Argon2id setup is 1GB (1048576 kb) for memory cost and the parallelism setting of 1-4 threads max.
These defaults were established to provide strong resistance to brute-force attacks by requiring significant computational resources, while capping parallelism to avoid excessive load on systems with limited cores. The memory cost ensures high RAM usage during key derivation, making GPU-based attacks more difficult, and the parallelism allows for multi-threaded processing up to 4 threads by default.
The iteration time is often set to around 2000 milliseconds, but memory and parallelism are the key parameters queried.
To verify these defaults you can use the cryptsetup luksDump command to inspect the current settings.
Anyway others places have suggested and discussed that if a user has sufficient RAM they should increase it more then the default (1GB) manually.
Should Kicksecure use 1/2 or 1/3 of the total memory or have an option to in Graphical installer to set this?
I think the latter since having a option for advanced installs rather then an “opt-in” one size fits all approach. That would provide for flexibility and user by user use case when installing Kicksecure.
- 1/2 available RAM example
--pbkdf-memory $(awk -F ' ' '/MemTotal/ {printf "%.0f\n", $2 / 2}' /proc/meminfo)
- 1/3 available RAM example
--pbkdf-memory $(awk -F ' ' '/MemTotal/ {printf "%.0f\n", $2 / 3}' /proc/meminfo)
Typically or my understanding is that cyrptsetup will detect the max amount of threads available by the system and will use that when setting parallel defaults.
Documenting how to upgrade a Luks Kicksecure install manually to increase the Argon2 memory cost might be worth mentioning.
2 Likes
Hmmm now you got me wondering if I should upgrade my luks install 
Increasing memory usage to match the running system seems like a good idea initially, but it could be playing with fire. What if someone installs Kicksecure on a machine with 16 GB RAM, then later that machine breaks and they need to boot the installation on a machine with only 4 GB RAM? Without arcane workarounds involving manual swapfile creation from a live ISO, that would become impossible if using half or even a third of available RAM at installation time. Similar issues could occur if a RAM chip fails and the user has to remove a stick of memory from their computer. On top of that, people use the Kicksecure ISO on very memory-low virtual machines, and it’s not beyond the realm of possibility some of them will be using disk encryption in those situations. Basing the memory requirements off of the system’s available memory would actually make security worse in some of these situations. So if we were to implement something like this, it would have to be an advanced option, not a default.
Calamares unfortunately does not call cryptsetup directly, it goes through libkpmcore, and libkpmcore does not currently provide a way to customize the options that are passed to cryptsetup. Debian Trixie is already frozen, so a new feature like this would probably not land in Kicksecure for a pretty long while and would require substantial work in both Calamares and libkpmcore to make it work.
It’s also worth noting that 1 GB memory usage already makes brute-force attacks against argon2id (with a decent passphrase) effectively impossible, to my awareness. Increasing memory usage even more does technically increase brute-force attack difficulty, but brute-force attacks are already so hard with argon2id that there’s no point, an attacker isn’t going to use a brute-force attack unless they think you chose a very weak passphrase. Therefore It’s much more important to pick a good passphrase and avoid leaking it.
(It’s also worth noting that the weakest link in modern computer security is usually the end-user. No amount of hardening, encryption, or “paranoid” security settings will help if a user is not very mindful of what they do with their computer. All the good password hashing settings in the world won’t help if a user then uses a dictionary word as their password, and uses that same dictionary word on all of the websites they use. It also won’t help if the user is forced to give up their passphrase, or if they give it to someone who they shouldn’t have trusted, or write it down on a piece of paper that an adversary later finds, or they visit a malicious website with an outdated web browser, etc., etc.)
If you really want to increase the memory usage of cryptsetup anyway, I believe cryptsetup luksChangeKey will allow you to do that. I’m not sure if we should document it since I don’t think we should be encouraging users to do this. Documenting how to take effectively useless measures to improve security could actually be detrimental, since a user could get caught up in applying every hardening setting they can find to their system, and fail to learn a mindset of caution that will have a practical impact on their security.
3 Likes
Due to this, we don’t have any plans to work on this.
However, note, that the Kicksecure project is not the final decision maker in this case. You don’t have to necessarily convince Kicksecure.
This is mostly unspecific to Kicksecure.
Feel free to discuss this with other upstream projects such as for example:
- Calamares
- libkpmcore
- cryptsetup
- Debian
Should other projects, upstreams agree with this proposal, their improvements, if any are ever made, would likely flow down to downstream, Kicksecure.
I’m with @arraybolt3 on this one with of keeping it at 1GB seems realistic and already a strong default. However If you feel the need to update it, I wouldn’t go more then 2-3 GB’s depending how much memory you have.
1 Like