to...@tuxteam.de writes:
On Wed, Mar 08, 2023 at 10:20:09AM -0500, rhkra...@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).
[...]
> * can files in the LUKS partition other than the one with the one block > corrupted be read correctly? Most probably yes (see below)
There is an interesting FAQ touching this subject at https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects
Specifically, section 6.5 “Do I need a backup of the full partition? Would the header and key-slots not be enough?” seems to go into the direction but is rather vague regarding the quantity of data affected by a single error.
To me it is quite plausible that small errors can corrupt larger armounts of data than "usually", but most likely not _all_ data if one excludes the precious metadata from the consideration.
[...]
> 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.
[...]It seems that earlier versions defaulted to CBC-ESSIV mode whereas new instances rely on XTS. Regarding their details, see
https://en.wikipedia.org/wiki/Disk_encryption_theory
I think one of the problems with a “plain” CTR instantiation is that it
fails when a file changes:
Say the counter value is based on the location on disk*** and the first entry with CTR=1 is considered. Now the file is encrypted as follows:
Ek(CTR=1) xor Plaintext1
Now the data at the location changes from Plaintext1 to Playintext2, then
naively, one could go on storing the new ciphertext as follows:
Ek(CTR=1) xor Plaintext2
But: The xor operation is only secure under the assumption of a “one time
pad” i.e. no reuse of the "key" which in this case would be a constant value
of Ek(CTR=1) for all plaintexts that are to be stored at that location.
***) This may be a simplification, but consider the alternatives... HTH Linux-Fan öö
pgp8k19yPur6M.pgp
Description: PGP signature
