linux-kernel - Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZxieZPlH-S9pakYW@infradead.org>
Date: Tue, 22 Oct 2024 23:57:40 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Adrian Vovk <adrianvovk@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
	Eric Biggers <ebiggers@...nel.org>,
	Md Sadre Alam <quic_mdalam@...cinc.com>, axboe@...nel.dk,
	song@...nel.org, yukuai3@...wei.com, agk@...hat.com,
	snitzer@...nel.org, Mikulas Patocka <mpatocka@...hat.com>,
	adrian.hunter@...el.com, quic_asutoshd@...cinc.com,
	ritesh.list@...il.com, ulf.hansson@...aro.org, andersson@...nel.org,
	konradybcio@...nel.org, kees@...nel.org, gustavoars@...nel.org,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-raid@...r.kernel.org, dm-devel@...ts.linux.dev,
	linux-mmc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-hardening@...r.kernel.org, quic_srichara@...cinc.com,
	quic_varada@...cinc.com
Subject: Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

On Fri, Oct 18, 2024 at 11:03:50AM -0400, Adrian Vovk wrote:
> Sure, but then this way you're encrypting each partition twice. Once by the dm-crypt inside of the partition, and again by the dm-crypt that's under the partition table. This double encryption is ruinous for performance, so it's just not a feasible solution and thus people don't do this. Would be nice if we had the flexibility though.

Why do you assume the encryption would happen twice?

> >Because you are now bypassing encryption for certainl LBA ranges in
> >the file system based on hints/flags for something sitting way above
> >in the stack.
> >
> 
> Well the data is still encrypted. It's just encrypted with a different key. If the attacker has a FDE dump of the disk, the data is still just as inaccessible to them.

No one knows that it actually is encryped.  The lower layer just knows
the skip encryption flag was set, but it has zero assurance data
actually was encrypted.