From: Alex Elsayed <eternaleye@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Experimental btrfs encryption
Date: Tue, 20 Sep 2016 02:47:17 +0000 (UTC) [thread overview]
Message-ID: <nrq7vk$j27$1@blaine.gmane.org> (raw)
In-Reply-To: a8dc3c28-5629-d870-f202-de35d2f941f1@fb.com
On Mon, 19 Sep 2016 20:32:34 -0400, Chris Mason wrote:
> On 09/19/2016 04:58 PM, Alex Elsayed wrote:
<snip>
>> When someone says "pretty simple" regarding cryptography, it's often
>> neither pretty nor simple :P
>>
>> The issue, here, is that inodes are fundamentally not a safe scope to
>> attach that information to in btrfs. As extents can be shared between
>> inodes (and thus both will need to decrypt them), and inodes can be
>> duplicated unmodified (snapshots), attaching keys and nonces to inodes
>> opens up a whole host of (possibly insoluble) issues, including
>> catastrophic nonce reuse via writable snapshots.
>
> I'm going to have to read harder about nonce reuse. In btrfs an inode
> is really a pair [ root id, inode number ], so strictly speaking two
> writable snapshots won't have the same inode in memory and when a
> snapshot is modified we'd end up with a different nonce for the new
> modifications.
>
> This would lead to a chain, where reading an single modified file in a
> snapshot might require multiple different keys. The btrfs metadata has
> what it needs to look these things up in the readpage call, but it ends
> up being much closer to per-extent encryption.
For reading about nonce reuse (and nonce-misuse-resistant AEAD), the best
option to start with is likely Hoang, Krovetz, and Rogaway's "Robust
Authenticated Encryption: AEZ and the problem it solves"
https://eprint.iacr.org/2014/793
For one of the first such schemes, it's likely of interest to read about
SIV (Rogaway and Shrimpton):
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/siv/
siv.pdf
A variant of SIV that can be efficiently realized using the same hardware
acceleration as AES-GCM is AES-GCM-SIV (Gueron, Lindell):
https://eprint.iacr.org/2015/102
And for information on how catastrophic _ever_ reusing the same (nonce,
key) pair is with plain GCM:
Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS
(Böck, Zauner, Devlin, Somorovsky, Jovanovic)
https://eprint.iacr.org/2016/475
(The same applies to ChaCha20-Poly1305, and the vast majority of other
AEADs that lack nonce-misuse-resistance).
next prev parent reply other threads:[~2016-09-20 2:47 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 13:39 [RFC] Preliminary BTRFS Encryption Anand Jain
2016-09-13 13:39 ` [PATCH] btrfs: Encryption: Add btrfs encryption support Anand Jain
2016-09-13 14:12 ` kbuild test robot
2016-09-13 14:24 ` kbuild test robot
2016-09-13 16:10 ` kbuild test robot
2016-09-13 13:39 ` [PATCH 1/2] btrfs-progs: make wait_for_commit non static Anand Jain
2016-09-13 13:39 ` [PATCH 2/2] btrfs-progs: add encryption support Anand Jain
2016-09-13 13:39 ` [PATCH] fstests: btrfs: support encryption Anand Jain
2016-09-13 16:42 ` [RFC] Preliminary BTRFS Encryption Wilson Meier
2016-09-14 7:02 ` Anand Jain
2016-09-14 18:26 ` Wilson Meier
2016-09-15 4:53 ` Alex Elsayed
2016-09-15 11:33 ` Anand Jain
2016-09-15 11:47 ` Alex Elsayed
2016-09-16 11:35 ` Anand Jain
2016-09-15 5:38 ` Chris Murphy
2016-09-15 11:32 ` Anand Jain
2016-09-15 11:37 ` Austin S. Hemmelgarn
2016-09-15 14:06 ` Anand Jain
2016-09-15 14:24 ` Austin S. Hemmelgarn
2016-09-16 8:58 ` David Sterba
2016-09-17 2:18 ` Zygo Blaxell
2016-09-16 1:12 ` Dave Chinner
2016-09-16 5:47 ` Roman Mamedov
2016-09-16 6:49 ` Alex Elsayed
2016-09-17 4:38 ` Zygo Blaxell
2016-09-17 6:37 ` Alex Elsayed
2016-09-19 18:08 ` Zygo Blaxell
2016-09-19 20:01 ` Alex Elsayed
2016-09-19 22:22 ` Zygo Blaxell
2016-09-19 22:25 ` Chris Murphy
2016-09-19 22:31 ` Zygo Blaxell
2016-09-20 1:10 ` Zygo Blaxell
2016-09-17 18:45 ` David Sterba
2016-09-20 14:26 ` Anand Jain
2016-09-16 10:45 ` Brendan Hide
2016-09-16 11:46 ` Anand Jain
2016-09-16 8:49 ` David Sterba
2016-09-16 11:56 ` Anand Jain
2016-09-17 20:35 ` David Sterba
2016-09-18 8:34 ` RAID1 availability issue[2], Hot-spare and auto-replace Anand Jain
2016-09-18 17:28 ` Chris Murphy
2016-09-18 17:34 ` Chris Murphy
2016-09-19 2:25 ` Anand Jain
2016-09-19 12:07 ` Austin S. Hemmelgarn
2016-09-19 12:25 ` Austin S. Hemmelgarn
2016-09-18 9:54 ` [RFC] Preliminary BTRFS Encryption Anand Jain
2016-09-20 0:12 ` Chris Mason
2016-09-20 0:55 ` Anand Jain
2016-09-17 6:58 ` Eric Biggers
2016-09-17 7:13 ` Alex Elsayed
2016-09-19 18:57 ` Zygo Blaxell
2016-09-19 19:50 ` Alex Elsayed
2016-09-19 22:12 ` Zygo Blaxell
2016-09-17 16:12 ` Anand Jain
2016-09-17 18:57 ` Chris Murphy
2016-09-19 15:15 ` Experimental btrfs encryption Theodore Ts'o
2016-09-19 20:58 ` Alex Elsayed
2016-09-20 0:32 ` Chris Mason
2016-09-20 2:47 ` Alex Elsayed [this message]
2016-09-20 2:50 ` Theodore Ts'o
2016-09-20 3:05 ` Alex Elsayed
2016-09-20 4:09 ` Zygo Blaxell
2016-09-20 15:44 ` Chris Mason
2016-09-21 13:52 ` Anand Jain
2016-09-20 4:05 ` Anand Jain
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='nrq7vk$j27$1@blaine.gmane.org' \
--to=eternaleye@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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 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.