On 10/20/22 17:40, Eric Biggers wrote:
On Thu, Oct 20, 2022 at 12:58:23PM -0400, Sweet Tea Dorminy wrote:+ +/* + * fscrypt_extent_context - the encryption context for an extent + * + * For filesystems that support extent encryption, this context provides the + * necessary randomly-initialized IV in order to encrypt/decrypt the data + * stored in the extent. It is stored alongside each extent, and is + * insufficient to decrypt the extent: the extent's owning inode(s) provide the + * policy information (including key identifier) necessary to decrypt. + */ +struct fscrypt_extent_context_v1 { + u8 version; + union fscrypt_iv iv; +} __packed;On the previous version I had suggested using a 16-byte nonce per extent, so that it's the same as the inode-based case. Is there a reason you didn't do that? - Eric
I probably misunderstood what you meant. For the direct-key case, the initial extent context is generated by copying the inode's nonce (and setting the lblk_num field to match the starting lblk of the extent, for all the policies). In theory, this should result in the same IVs being used for unshared extents as would have happened for inode-based encryption?
|