[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump"

On 3/8/23 07:20, rhkramer@gmail.com wrote:

I am curious about the integrity of LUKS (that is, the ability to preserve
data in the event of corruption on the disk or such).

Aside: I know that backups are a solution / requirement (and I have some
(well, one, atm)), and I know that there is the ability to backup (and
restore) the LUKS headers in particular, but my question is something like
this:

The question:  Suppose disk corruption corrupts one block in the data storage
area of a LUKS partition / filesystem (I'm not asking about corruption in the
headers or some other area of "metadata").  In the case of one block of
corruption in the data storage area:

    * can files in the LUKS partition other than the one with the one block
corrupted be read correctly?

    * assuming the file with the corrupted block is bigger than one block, can
the other parts of the file (not including the corrupted block) be read
correctly?

Something I don't know is whether LUKS does encryption separately for each
block (or maybe for each file) or whether somehow the result of encryption is
one big "lump" of data (all files intermixed in the filesystem) and if
corruption of any individual block will render the entire filesystem
unreadable.  (As I write this, I'm tending to believe that it is the former,
but curious minds want to know (and I think I have a life or two left ;-) .)

I have done some googling on this, but haven't found the magic combination of
keywords.  Some of the searches I tried:

    * [LUKS partition zero before formatting]
    * [encrypted filesystem power loss]
    * [LUKS one block corrupted]

More background: in searching to understand the reason for zeroing the LUKS
partition before utilizing it (either before or after the luksFormat step)
(which I now understand -- in short, it is to fill it with random data!), I
found a recommendation: "Note that when the encryption is in use, we need to
turn off write caching for our disk."

I wanted to try to understand why write caching should be turned off, or if an
encrypted filesystem is any more vulnerable to loss (corruption) of one block
than a non-encrypted filesystem.
I use LUKS on disk partitions. In the past, I have used LUKS on lvm(8) and mdadm(8) volumes.
I do not bother randomizing discs before using LUKS. I doubt this is going to stop a skilled attacker. And, I like being able to fstrim(8) my SSD's before taking an image.
I have noticed that some of my enterprise HDD's came with caching disabled. I need to check this again.
A few years ago, I did a "bit rot" experiment. I wiped a disk, applied a partitioning scheme, created a partition, formatted the partition with LUKS (with default encryption), opened the LUKS container, created an ext4 filesystem, mounted the filesystem, and wrote a large file containing a predictable pattern. I used hexdump(1) to find the encrypted blocks on disk that corresponded to the file. I used dd(1) to write directly to the disk and change some portion of a block underlying the file. I then viewed the file contents with standard userland tools (e.g. less(1)). To my dismay, the tools could read the file without error and the file contents were corrupt! I seem to recall that the number of damaged bytes was the same on disc and in the file.
As other readers have suggested, changing the encryption algorithm and/or settings may change the effects..
I wanted a storage system that can detect bit rot. The two choices I am aware of are Btrfs and ZFS. I had previously tried Btrfs as a root filesystem on Debian, and did not like the need for manual maintenance. So, I built a FreeBSD server with boot and root on ZFS, data storage on ZFS mirrored GELI HDD's, and moved my bulk data. 


I have been waiting for dm-integrity for Debian:

https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html
Due to licensing, I doubt there will ever be a d-i that supports Debian boot and root on ZFS. 


I have considered adding checksum files for my backups.  mtree(8) works;

https://www.techrepublic.com/article/use-mtree-for-filesystem-integrity-auditing/

https://linux.die.net/man/8/mtree


David
Reply to: