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). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
