Re: [dev] Disk encryption
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
Received on Wed Jun 15 2022 - 21:47:53 CEST
This archive was generated by hypermail 2.3.0
: Wed Jun 15 2022 - 22:36:07 CEST