From: Paul Crowley <paulcrowley@google.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>,
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: Mon, 28 Nov 2022 12:34:46 -0800 [thread overview]
Message-ID: <CA+_SqcCFepKXXJWhF=d4pcEpMZ5XFO6j9buc+aHKpX9sP2+_KA@mail.gmail.com> (raw)
In-Reply-To: <Y4RqbKSdxQ5owg0h@infradead.org>
The kind of inline encryption hardware we see on Android devices tends
to have these limitations:
- as you indicate, loading keys can incur latency, so if many keys are
in use at once it can slow things down
- it's limited to using AES-XTS
- on UFS devices, the IV (transmitted in the DUN) must be zero in the
64 high bits
- consecutive blocks in the same operation use consecutive IVs
- there's no easy way to gather a checksum or MAC over the on-disk
ciphertext short of re-reading after writing
Android works around this with IV_INO_LBLK_64 policies, but these only
work well on the relatively small storage devices we use on Android.
In particular the IV limitation is very serious:
- inode numbers must be four bytes
- they must never change (so ext4 filesystem resizing is disabled)
- files cannot be more than 2^32 blocks
Things are worse on eMMC devices.
Even without this IV limitation, the security proofs for most AES
modes of operation start to look shaky as you approach the "birthday
bound" of encrypting 2^68 bytes with the same key. If your attack
model always assumes a point-in-time attack then you only have to
worry if you use a single key to encrypt a multi-exabyte storage
device; btrfs is designed to scale to such devices and more. If your
attack model includes an attacker who repeatedly gets access to the
storage device across time, then writing multiple exabytes with the
same key can be a problem even if some of those are overwritten. This
leads us to prefer per-extent AES keys (derived from a root key) if
possible. It's a shame AES doesn't have a 256-bit blocksize.
The way btrfs works also gives us some opportunities to do things a
little better. In general disk encryption has to make sacrifices to
deal with the limitation that IVs must be reused and there's no room
for a MAC. But because btrfs writes in whole extents, with fresh
metadata and checksum on each write, it becomes possible to use a
fresh IV and MAC for every new write. This opens up the possibility of
using an AEAD mode like AES-GCM. This combination gives us the
strongest proofs of security even against very generous attack models.
Our recommendation: btrfs should first build the ideal thing first
since it will have reasonable performance for most users, then later
design alternatives that make a few compromises for performance where
there is demand.
On Sun, 27 Nov 2022 at 23:59, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Nov 23, 2022 at 08:22:30PM -0500, Sweet Tea Dorminy wrote:
> > 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
>
> How is this going to work with hardware encryption offload? I think
> the number of keys for UFS and eMMC inline encryption, but Eric may
> correct me.
prev parent reply other threads:[~2022-11-28 20:35 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
2022-11-28 7:59 ` Christoph Hellwig
2022-11-28 18:44 ` Eric Biggers
2022-11-28 20:34 ` Paul Crowley [this message]
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='CA+_SqcCFepKXXJWhF=d4pcEpMZ5XFO6j9buc+aHKpX9sP2+_KA@mail.gmail.com' \
--to=paulcrowley@google.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=hch@infradead.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=sweettea-kernel@dorminy.me \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).