[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 Wed, Mar 08, 2023 at 10:20:09AM -0500, 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?

Most probably yes (see below)

>    * 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 [...]

This hints at the difference of CBC and counter modes [1]. If you
encrypt each block separately with the same key (this mode is called
ECB "electronic code book"), you end up with a schema in which equal
blocks encrypt to equal encrypted values, which gives away quite a
bit of your content (nice pic here [2]).

The traditional way to counter this is to mix part (well, kind of)
of the block you just encrypted into the next block, this is called
CBC for "cipher block chaining". This is fine for streams of blocks
(think TLS), but not so nice for a hard disk, where you'd like to
have random block access.

The solution is to take some hashy function of the block's number
itself into the blocks encription. This is called CTR (aka counter
mode).

I haven't looked deeply into Luks (which would be Luks2 these days).
As far as I know, Luks only manages all that stuff (key management,
algorithms, modes, etc.). But I'm pretty sure that whichever algo
is beneath that is using CTR mode.

Cheers

[1] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality_only_modes
   and following
[2] https://words.filippo.io/the-ecb-penguin/

-- 
t

Attachment: signature.asc
Description: PGP signature


Reply to: