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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALrw=nFABteNOAOpvaGOMrpUOMW1LMJfRB5EXxs_dPH70G_LGQ@mail.gmail.com>
Date: Tue, 14 May 2024 17:01:03 +0100
From: Ignat Korchagin <ignat@...udflare.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, Mimi Zohar <zohar@...ux.ibm.com>, 
	David Howells <dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, serge@...lyn.com, linux-integrity@...r.kernel.org, 
	keyrings@...r.kernel.org, linux-kernel@...r.kernel.org, 
	kernel-team@...udflare.com
Subject: Re: [RFC PATCH 0/2] TPM derived keys

On Tue, May 14, 2024 at 4:54 PM James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> On Tue, 2024-05-14 at 16:38 +0100, Ignat Korchagin wrote:
> > On Tue, May 14, 2024 at 4:30 PM James Bottomley
> > <James.Bottomley@...senpartnership.com> wrote:
> > >
> > > On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> > > >   * if someone steals one of the disks - we don't want them to
> > > > see it has encrypted data (no LUKS header)
> > >
> > > What is the use case that makes this important?  In usual operation
> > > over the network, the fact that we're setting up encryption is
> > > easily identifiable to any packet sniffer (DHE key exchanges are
> > > fairly easy to fingerprint), but security relies on the fact that
> > > even knowing that we're setting up encryption, the attacker can't
> > > gain access to it.  The fact that we are setting up encryption
> > > isn't seen as a useful thing to conceal, so why is it important for
> > > your encrypted disk use case?
> >
> > In some "jurisdictions" authorities can demand that you decrypt the
> > data for them for "reasons". On the other hand if they can't prove
> > there is a ciphertext in the first place - it makes their case
> > harder.
>
> Well, this isn't necessarily a good assumption: the way to detect an
> encrypted disk is to look at the entropy of the device blocks.  If the
> disk is encrypted, the entropy will be pretty much maximal unlike every
> other use case.  The other thing is that if the authorities have your

What if the disk is filled with random data? Would it not be at maximal entropy?

> TPM, they already have access to the disk in this derived key scenario.

I'm thinking more of a datacenter scenario here - it is much easier to
"steal" a disk rather than a server from a datacenter. So it is
possible that someone has the disk but no access to the TPM.

> If *you* still have access to your TPM, you can update the storage seed
> to shred the data.

The point here is not if I was able to shred the data or not, but the
fact I have something encrypted. Even if I shred the key I would be
considered "uncooperative and refusing to provide the key" vs "I don't
have anything encrypted in the first place".

> James
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ