From: Eric Biggers <ebiggers@kernel.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-fscrypt@vger.kernel.org,
Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [RFC PATCH v3 00/18] fscrypt: key management improvements
Date: Tue, 19 Feb 2019 23:54:05 -0800 [thread overview]
Message-ID: <20190220075404.GA974@sol.localdomain> (raw)
In-Reply-To: <1660609D-3525-4485-9652-57976DB020F4@dilger.ca>
On Tue, Feb 19, 2019 at 11:18:21PM -0800, Andreas Dilger wrote:
> On Feb 19, 2019, at 10:52 PM, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > Hello,
> >
> > This patchset makes major improvements to how keys are added, removed,
> > and derived in fscrypt, aka ext4/f2fs/ubifs encryption. It does this by
> > adding new ioctls that add and remove encryption keys directly to/from
> > the filesystem, and by adding a new encryption policy version ("v2")
> > where the user-provided keys are only used as input to HKDF-SHA512 and
> > are identified by their cryptographic hash.
>
> Just to confirm for the layman reader - the fact that the crypto keys
> are registered with the filesystem and not with the user process doesn't
> prevent user(s) from having different crypto keys for different subdirs
> in a single filesystem?
Correct, that hasn't changed. Different directories can use different keys.
>
> Secondly, does this progress fscrypt toward allowing multiple master keys
> to decrypt a single per-file key?
>
It's not a goal of this patchset as no one has really been asking for it yet.
Per-file keys are still derived from the master key.
Note that it's already possible to wrap the master keys in userspace. Thus you
can already have multiple passwords that unlock the same encrypted directory.
You just can't do this with *individual files*. Maybe that's good enough.
However, this patchset does fix the denial of service vulnerabilities that
currently exist when users share an encrypted directory. Also, since it adds a
real KDF, it makes it much easier to derive a wrapping key to wrap the per-file
keys if that were to become a requirement. (The master key could be used as the
wrapping key directly, but that's inflexible and more error-prone.)
- Eric
next prev parent reply other threads:[~2019-02-20 7:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 6:52 [RFC PATCH v3 00/18] fscrypt: key management improvements Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 01/18] fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 02/18] fscrypt: use FSCRYPT_ prefix for uapi constants Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 03/18] fscrypt: use FSCRYPT_* definitions, not FS_* Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 04/18] fs: add ->s_master_keys to struct super_block Eric Biggers
2019-02-20 23:19 ` Richard Weinberger
2019-02-20 6:52 ` [RFC PATCH v3 05/18] fscrypt: add ->ci_inode to fscrypt_info Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 06/18] fscrypt: refactor v1 policy key setup into keysetup_legacy.c Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 07/18] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl Eric Biggers
2019-02-20 23:52 ` Richard Weinberger
2019-02-21 5:49 ` Eric Biggers
2019-02-21 9:33 ` Richard Weinberger
2019-02-21 18:42 ` Eric Biggers
2019-03-18 23:08 ` Eric Biggers
2019-03-22 22:02 ` Richard Weinberger
2019-02-20 6:52 ` [RFC PATCH v3 08/18] fs/dcache.c: add shrink_dcache_inode() Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 09/18] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 10/18] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 11/18] fscrypt: add an HKDF-SHA512 implementation Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 12/18] fscrypt: v2 encryption policy support Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 13/18] fscrypt: allow unprivileged users to add/remove keys for v2 policies Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 14/18] fscrypt: require that key be added when setting a v2 encryption policy Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 15/18] ext4: wire up new fscrypt ioctls Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 16/18] f2fs: " Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 17/18] ubifs: " Eric Biggers
2019-02-20 6:52 ` [RFC PATCH v3 18/18] fscrypt: document the new ioctls and policy version Eric Biggers
2019-02-20 7:18 ` [RFC PATCH v3 00/18] fscrypt: key management improvements Andreas Dilger
2019-02-20 7:54 ` Eric Biggers [this message]
2019-02-20 18:07 ` David Howells
2019-02-20 18:36 ` 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=20190220075404.GA974@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=adilger@dilger.ca \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paulcrowley@google.com \
--cc=satyat@google.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).