All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	kernel@pengutronix.de, James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Sumit Garg <sumit.garg@linaro.org>,
	David Howells <dhowells@redhat.com>,
	linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fscrypt: support trusted keys
Date: Tue, 10 Aug 2021 11:46:49 -0700	[thread overview]
Message-ID: <YRLJmaafp941uOdA@gmail.com> (raw)
In-Reply-To: <20210810180636.vqwaeftv7alsodgn@kernel.org>

On Tue, Aug 10, 2021 at 09:06:36PM +0300, Jarkko Sakkinen wrote:
> > > 
> > > I don't think this is right, or at least it does not follow the pattern
> > > in [*]. I.e. you should rather use trusted key to seal your fscrypt key.
> > 
> > What's the benefit of the extra layer of indirection over just using a "trusted"
> > key directly?  The use case for "encrypted" keys is not at all clear to me.
> 
> Because it is more robust to be able to use small amount of trusted keys,
> which are not entirely software based.
> 
> And since it's also a pattern on existing kernel features utilizing trusted
> keys, the pressure here to explain why break the pattern, should be on the
> side of the one who breaks it.

This is a new feature, so it's on the person proposing the feature to explain
why it's useful.  The purpose of "encrypted" keys is not at all clear, and the
documentation for them is heavily misleading.  E.g.:

    "user space sees, stores, and loads only encrypted blobs"
    (Not necessarily true, as I've explained previously.)

    "Encrypted keys do not depend on a trust source" ...  "The main disadvantage
    of encrypted keys is that if they are not rooted in a trusted key"
    (Not necessarily true, and in fact it seems they're only useful when they
    *do* depend on a trust source.  At least that's the use case that is being
    proposed here, IIUC.)

I do see a possible use for the layer of indirection that "encrypted" keys are,
which is that it would reduce the overhead of having lots of keys be directly
encrypted by the TPM/TEE/CAAM.  Is this the use case?  If so, it needs to be
explained.

- Eric

  reply	other threads:[~2021-08-10 18:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 15:09 Ahmad Fatoum
2021-08-09  9:44 ` Jarkko Sakkinen
2021-08-09 10:00   ` Ahmad Fatoum
2021-08-09 10:02     ` Ahmad Fatoum
2021-08-10 18:02     ` Jarkko Sakkinen
2021-08-09 20:52   ` Eric Biggers
2021-08-10 18:06     ` Jarkko Sakkinen
2021-08-10 18:46       ` Eric Biggers [this message]
2021-08-10 21:21         ` Jarkko Sakkinen
2021-08-10 21:27           ` Eric Biggers
2021-08-11  0:17             ` Jarkko Sakkinen
2021-08-11 11:34               ` Mimi Zohar
2021-08-11 17:16                 ` Eric Biggers
2021-08-12  0:54                   ` Mimi Zohar
2021-08-17 13:04                     ` Ahmad Fatoum
2021-08-17 13:55                       ` Mimi Zohar
2021-08-17 14:13                         ` Ahmad Fatoum
2021-08-17 14:24                           ` Mimi Zohar
2021-08-18  2:09                             ` Jarkko Sakkinen
2021-08-18  4:53                             ` Sumit Garg
2021-08-09 21:24 ` Eric Biggers
2021-08-10  7:41   ` Ahmad Fatoum
2021-08-10 17:35     ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRLJmaafp941uOdA@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=a.fatoum@pengutronix.de \
    --cc=dhowells@redhat.com \
    --cc=jaegeuk@kernel.org \
    --cc=jarkko@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=kernel@pengutronix.de \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=sumit.garg@linaro.org \
    --cc=tytso@mit.edu \
    --cc=zohar@linux.ibm.com \
    --subject='Re: [PATCH v2] fscrypt: support trusted keys' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.