Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #255710

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

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

tomas@tuxteam.de writes:

> 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).

[...]

> >    * 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

öö

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump" rhkramer@gmail.com - 2023-03-08 16:30 +0100
  Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" <tomas@tuxteam.de> - 2023-03-08 18:20 +0100
    Re: Subject: OT: LUKS encryption -- block by block, file by file,          or "one big lump" Linux-Fan <Ma_Sys.ma@web.de> - 2023-03-08 22:10 +0100
  Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" David Christensen <dpchrist@holgerdanske.com> - 2023-03-09 03:50 +0100
    Re: Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump" rhkramer@gmail.com - 2023-03-09 16:00 +0100
      Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" David Christensen <dpchrist@holgerdanske.com> - 2023-03-09 22:10 +0100
        Re: Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump" rhkramer@gmail.com - 2023-03-10 01:30 +0100
  Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" Nicolas George <george@nsup.org> - 2023-03-09 22:20 +0100
    Re: Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump" rhkramer@gmail.com - 2023-03-10 01:30 +0100
      Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" Nicolas George <george@nsup.org> - 2023-03-10 09:00 +0100
        Re: Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump" rhkramer@gmail.com - 2023-03-10 13:30 +0100
    Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" "Bottenberg, Michael" <michael@der-he.de> - 2023-03-10 17:00 +0100
      Re: Subject: OT: LUKS encryption -- block by block, file by file, or  "one big lump" Nicolas George <george@nsup.org> - 2023-03-10 17:10 +0100

csiph-web