libkpmcore is capable of making LUKS2 encrypted volumes. This is done ultimately by calling cryptsetup with some hardcoded arguments that should provide reasonably secure disk encryption settings.
There are a few things that are non-ideal here:
- The settings are not as secure as they could be. Quite a few of them are left up to cryptsetup and the distro’s defaults to decide, which could result in a reduction in security (less secure algorithms in use, less secure methods of random number generation used, less secure hashing, etc).
- The settings are hardcoded and thus hard to change. For a distro that is very security-focused, they may want to enable every possible security option there is in order to keep the end-user safe, even if that comes at the expense of speed. An embedded or low-power system on the other hand might be crippled by those kinds of settings and require less “paranoid” (for lack of a better term) settings for performance reasons.
- The settings require the developer to trust that the library’s settings are good and correct and always will be. Were a supply chain attack to happen and the attacker managed to set the password hashing function to something totally useless like
xxhash, that could be hard to recover from.
libkpmcore is used beyond just KDE Partition Manager - in particular, Calamares uses it to do disk partitioning tasks during system installation. When you choose to enable encryption there, libkpmcore’s default cryptsetup settings are used. For context, the settings libkpmcore uses now are here, whereas significantly more secure settings can be seen here.
Some of these are harder to fix than others, but the first one seems relatively easy to fix by strengthening the default cryptsetup settings used by libkpmcore. This would potentially come with a small performance hit, but as computers get faster it seems that’s something we can afford and something that is necessary to avoid problems.
The alternative would be to extend libkpmcore such that an application could customize what LUKS settings it wanted to use. This would neatly solve the second problem and alleviate the third problem as well. It would also take quite a bit longer to actually implement, as it would require adding support for this to libkpmcore, and then also implementing it in applications that consume libkpmcore (such as Calamares).
Thoughts?