From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Paul Crowley <paulcrowley@google.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
kernel-team@meta.com, Omar Sandoval <osandov@osandov.com>,
Chris Mason <clm@fb.com>
Subject: Re: [PATCH v5 00/18] btrfs: add fscrypt integration
Date: Wed, 23 Nov 2022 20:22:30 -0500 [thread overview]
Message-ID: <4857f0df-dae0-178e-85e3-307197701d34@dorminy.me> (raw)
In-Reply-To: <55686ed2-b182-3478-37aa-237e306be6e1@dorminy.me>
We had a very productive meeting and have greatly changed the design: we
now plan to implement authenticated encryption, and have per-extent keys
instead of per-extent nonces, which will greatly improve the
cryptographic characteristics over this version. Many thanks for the
discussion, both in the meeting and on the document.
The document has been updated to hopefully reflect the discussion we
had; further comments are always appreciated.
https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
I look forward to working on implementing the new design; thanks to all!
Sweet Tea
On 11/21/22 12:26, Sweet Tea Dorminy wrote:
> I appreciate the conversation happening on the doc; thank ya'll for
> reading and commenting.
>
> Would it be worth having a meeting on Zoom or the like this week to
> discuss the way forward for getting encryption for btrfs, be that one of
> the extent-based encryption variations or AEAD?
>
> Thanks!
>
> Sweet Tea
>
> On 11/16/22 15:19, Sweet Tea Dorminy wrote:
>>
>>
>> On 11/3/22 15:22, Paul Crowley wrote:
>>> Thank you for creating this! I'm told the design document [1] no
>>> longer reflects the current proposal in these patches. If that's so I
>>> think it's worth bringing the design document up to date so we can
>>> review the cryptography. Thanks!
>>>
>>> [1]
>>> https://docs.google.com/document/d/1iNnrqyZqJ2I5nfWKt7cd1T9xwU0iHhjhk9ALQW3XuII/edit
>>
>> I apologize for the delay; I realized when this thread was bumped just
>> now that my attempt to share the updated doc didn't seem to make it to
>> the mailing list.
>>
>> https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing is an update of the design document that hopefully is what you're requesting.
next prev parent reply other threads:[~2022-11-24 1:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 11:52 [PATCH v5 00/18] btrfs: add fscrypt integration Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 01/18] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 02/18] fscrypt: add fscrypt_have_same_policy() to check inode compatibility Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 03/18] fscrypt: allow fscrypt_generate_iv() to distinguish filenames Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 04/18] fscrypt: add extent-based encryption Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 05/18] fscrypt: extent direct key policies for " Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 06/18] fscrypt: document btrfs' fscrypt quirks Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 07/18] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 08/18] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 09/18] btrfs: add fscrypt_context items Sweet Tea Dorminy
2022-11-02 11:52 ` [PATCH v5 10/18] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 11/18] btrfs: store a fscrypt extent context per normal file extent Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 12/18] btrfs: encrypt normal file extent data if appropriate Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 13/18] btrfs: Add new FEATURE_INCOMPAT_ENCRYPT feature flag Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 14/18] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 15/18] btrfs: permit searching for nokey names for removal Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 16/18] btrfs: use correct name hash for nokey names Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 17/18] btrfs: encrypt verity items Sweet Tea Dorminy
2022-11-02 11:53 ` [PATCH v5 18/18] btrfs: allow encrypting compressed extents Sweet Tea Dorminy
2022-11-03 19:22 ` [PATCH v5 00/18] btrfs: add fscrypt integration Paul Crowley
2022-11-16 20:08 ` Neal Gompa
2022-11-16 20:35 ` Eric Biggers
2022-11-16 20:19 ` Sweet Tea Dorminy
2022-11-21 17:26 ` Sweet Tea Dorminy
2022-11-24 1:22 ` Sweet Tea Dorminy [this message]
2022-11-28 7:59 ` Christoph Hellwig
2022-11-28 18:44 ` Eric Biggers
2022-11-28 20:34 ` Paul Crowley
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=4857f0df-dae0-178e-85e3-307197701d34@dorminy.me \
--to=sweettea-kernel@dorminy.me \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=paulcrowley@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).