[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 Thursday, March 09, 2023 04:16:14 PM Nicolas George wrote:
> rhkramer@gmail.com (12023-03-08):
> > 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?
> 
> Of course not. 

Didn't you mean "of course"?

> Anything that would require LUKS to read several
> encrypted blocks for each cleartext block read from it or the same
> s/read/write/ would ruin the performances in a way that nobody would
> accept.
> 
> Therefore, each block on the LUKS cleartext side must map to one block
> on the encrypted side and must be encrypted in a completely
> self-contained way, entirely independent of the contents of other
> blocks.
> 
> Ensuring the integrity of the data is not part of the attributions of
> LUKS either. It could, but then again it would cost performance. And
> space, at least 1/1000, probably more around 1/256 or 1/128.
> 
> Regards,

-- 
rhk 

(sig revised 20230224 -- added first paragraph)
                
| You do not have my permission to use this email to train an AI. 

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking.  (Remember Cicero who did 
not have enough time to write a short missive.)  (That speaker might have been 
"trained" to do this by being interrupted often if he pauses.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'


Reply to: