lkml.org 
[lkml]   [2024]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] TPM derived keys
On Tue May 14, 2024 at 5:41 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 3:00 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > For example, a cheap NAS box with no internal storage (disks connected
> > > externally via USB). We want:
> > > * disks to be encrypted and decryptable only by this NAS box
> >
> > So how this differs from LUKS2 style, which also systemd supports where
> > the encryption key is anchored to PCR's? If I took hard drive out of my
> > Linux box, I could not decrypt it in another machine because of this.
>
> It differs with the fact that the disk has a clearly identifiable
> LUKS2 header, which tells an adversary that this is a disk with some
> data that is encrypted. With derived keys and plain dm-crypt mode
> there is no LUKS header, so it is not possible to tell if it is an
> encrypted disk or a disk with just random data. Additionally, if I
> accidentally wipe the sector with the LUKS2 header - all my data is
> lost (because the data encryption key from the header is lost). With
> derived keys I can always decrypt at least some data, if the disk is
> available.

I figured most of this out myself and sent a follow-up but yeah thnaks
for confirming my toughts. I get this part now.

Follow-ups to my follow-up...

BR, Jarkko

\
 
 \ /
  Last update: 2024-05-27 18:26    [W:0.078 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site