On Wed, Jun 15, 2022 at 12:49:07PM -0500, T Taylor Gurney wrote: > All, > > Working on another statically-linked Linux distro. > > Getting an encrypted root partition is a problem. The kernel has built-in > support for this and I am plenty familiar with it. But the supporting > userspace tool, cryptsetup, is way too bloated and has too many dependencies, > including OpenSSL. > > Anyone know of a more minimal alternative solution, or even have any > half-baked ideas for one? loop-AES looks most promising so far, but patching > the kernel and util-linux programs is not my preference. > > Taylor >
This is really where the devil is in the details, isn't it? The kernel has builtin support for disk encryption, but it does not have built-in support for LUKS. LUKS is a crypto-header solution that adds some kind of header to the volume which establishes (with help of the correct password, of course) the disk key. Truecrypt works in a similar fashion. This means, the setup utility has to do at least some crypto on its own, and then you can really only pick your poison. I just wanted to check what other backends cryptsetup supports, but the package requires autohell, and naturally it failed on me right out the gate. Apparently, however, libgcrypt can be used instead of OpenSSL. I don't know if that helps any. If you are willing to forego LUKS, you can roll your own dm-crypt solution, of course, just as soon as you have figured out how to securely make a key from a password. You can use PBKDF2 for that, or bcrypt. In theory, that ought to be secure. But consider the downsides. For example, if you generate the key directly out of the password, then you cannot change the password. Ever. Doing so would wipe the drive. Adding a layer of indirection here (encrypt drive with random key, save random key encrypted in first sector) would remedy the issue but also increase complexity. Again, pick your poison. Why would you need to patch util-linux for loop-AES? And would it work with dm-crypt? Ciao, Markus
