Customize LUKS options during install

[ghost]

Is your feature request related to a problem? Please describe.
The default LUKS encryption options do not meet the needs of some use cases.

Describe the solution you'd like
Introduce a feature that allows users to specify their encryption preferences through a configuration file, luks_config.conf, which can be edited within the live environment. This would enable users to customize the default settings for cipher, key size, hash algorithm, PBKDF options, and header label according to their specific requirements.

Describe alternatives you've considered
Currently, there appears to be no option to modify the default LUKS settings used by the installer, which restricts users to a one-size-fits-all approach.

Additional context
Security researchers have differing opinions on the "most secure" configuration. Allowing informed users to customize their settings creates a more complex challenge for attackers, enhancing overall security.

[dalto8]

Two comments from me:

• If these options were to be added, from a Calamares perspective, I think they would belong in partition.conf with the other luks-related settings.
• Does kpmcore support specifying these options? If it does, this would be fairly easy to implement I think. If not, support would need to be added there first.

[ghost]

I’m new to modifying Calamares and would appreciate any guidance on locating the current LUKS configuration in the source code or any relevant files within the installation environment. Any pointers would be helpful.

[dalto8]

They are in the partition module or something that is called from that module.

Unfortunately, that is the most complicated module and a bit of a tough place to start. That being said, you can pretty easily search it for "luks" and find all the places luks-related things are happening.

[ArrayBolt3]

These options are currently hardcoded into libkpmcore (which in some but not all areas falls back to whatever cryptsetup's defaults are for your distro). So it would require libkpmcore to implement this first.

I'm not entirely sure about the disagreements as to what is secure, I was under the impression that it was generally understood which options were stronger than others, and that it was only in situations where resource consumption was a concern that less strong options were worth considering. I could be wrong there though.

For reference, Kicksecure is currently dissatisfied with the default settings for LUKS2 in libkpmcore, and so we opted to propose strengthening those settings upstream. https://invent.kde.org/system/kpmcore/-/merge_requests/54

[ghost]

Thank you for your insights. Please feel free to close this issue if it should be directed elsewhere.

To clarify the considerations surrounding encryption schemes, I wrote a brief overview.

Encryption methods vary in their security levels, typically classified as secure, compromised, or those that prioritize speed over theoretical security.

For example, if five hard drives are encrypted with AES and it is subsequently compromised, all drives are at risk. Conversely, employing five distinct encryption algorithms ensures that only the AES-encrypted drive would be vulnerable.

This principle extends to operating system drive encryption as well. Five Linux machines encrypted with AES would be less secure than if each utilized a different secure cipher.

In essence, diversifying encryption methods complicates attacks, thereby enhancing overall security. An attacker exploiting default AES settings would be ill-prepared for a volume encrypted with Twofish and Argon2id. Even minor adjustments to default settings can significantly improve security by increasing unpredictability.

(Note: This is not a critique of AES specifically; it is just the default, though relying solely on it is inherently less secure than employing a variety of ciphers across different disks or volumes, particularly in high-security contexts.)