On Mon, Oct 21, 2019 at 04:03:53PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > Some inline encryption hardware has only a small number of keyslots, > which would make it inefficient to use the traditional fscrypt per-file > keys. The existing DIRECT_KEY encryption policy flag doesn't solve this > because it assumes that file contents and names are encrypted by the > same algorithm and that IVs are at least 24 bytes. > > Therefore, add a new encryption policy flag INLINE_CRYPT_OPTIMIZED which > causes the encryption to modified as follows: > > - The key for file contents encryption is derived from the values > (master_key, mode_num, filesystem_uuid). The per-file nonce is not > included, so many files may share the same contents encryption key. > > - The IV for encrypting each block of file contents is built as > (inode_number << 32) | file_logical_block_num. > > Including the inode number in the IVs ensures that data in different > files is encrypted differently, despite per-file keys not being used. > Limiting the inode and block numbers to 32 bits and putting the block > number in the low bits is needed to be compatible with inline encryption > hardware which only supports specifying a 64-bit data unit number which > is auto-incremented; this is what the UFS and EMMC standards support. These 32 bit size limits seem arbitrary and rules out implementing this on larger filesystems. Why not just hash the 64 bit inode, file offset and block numbers into a single 64 bit value? It is still unique enough for the stated use (i.e. unique IV for each file block) but it doesn't limit what filesystem configurations can actually make use of this functionality.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
