On Mon, 19 Sep 2016 20:32:34 -0400, Chris Mason wrote:

> On 09/19/2016 04:58 PM, Alex Elsayed wrote:


>> 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"


For one of the first such schemes, it's likely of interest to read about 
SIV (Rogaway and Shrimpton):


A variant of SIV that can be efficiently realized using the same hardware 
acceleration as AES-GCM is AES-GCM-SIV (Gueron, Lindell):


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)

(The same applies to ChaCha20-Poly1305, and the vast majority of other 
AEADs that lack nonce-misuse-resistance).

To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to