Linux-Crypto Archive on
 help / color / Atom feed
From: Eric Biggers <>
To: "Theodore Y. Ts'o" <>
	Satya Tangirala <>,
	Jaegeuk Kim <>,
	Paul Crowley <>
Subject: Re: [PATCH] fscrypt: add support for IV_INO_LBLK_32 policies
Date: Tue, 19 May 2020 07:45:01 -0700
Message-ID: <20200519144501.GA857@sol.localdomain> (raw)
In-Reply-To: <>

On Tue, May 19, 2020 at 07:13:21AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 15, 2020 at 01:41:41PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <>
> > 
> > The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
> > bits), unlike UFS's 64.  IV_INO_LBLK_64 is therefore not applicable, but
> > an encryption format which uses one key per policy and permits the
> > moving of encrypted file contents (as f2fs's garbage collector requires)
> > is still desirable.
> > 
> > To support such hardware, add a new encryption format IV_INO_LBLK_32
> > that makes the best use of the 32 bits: the IV is set to
> > 'SipHash-2-4(inode_number) + file_logical_block_number mod 2^32', where
> > the SipHash key is derived from the fscrypt master key.  We hash only
> > the inode number and not also the block number, because we need to
> > maintain contiguity of DUNs to merge bios.
> > 
> > Unlike with IV_INO_LBLK_64, with this format IV reuse is possible; this
> > is unavoidable given the size of the DUN.  This means this format should
> > only be used where the requirements of the first paragraph apply.
> > However, the hash spreads out the IVs in the whole usable range, and the
> > use of a keyed hash makes it difficult for an attacker to determine
> > which files use which IVs.
> > 
> > Besides the above differences, this flag works like IV_INO_LBLK_64 in
> > that on ext4 it is only allowed if the stable_inodes feature has been
> > enabled to prevent inode numbers and the filesystem UUID from changing.
> > 
> > Signed-off-by: Eric Biggers <>
> Reviewed-by: Theodore Ts'o <>
> I kind of wish we had Kunit tests with test vectors, but that's for
> another commit I think.

We do have ciphertext verification tests in xfstests for all the existing
fscrypt options.  Actually, I had hacked one together for IV_INO_LBLK_32 before
sending this patch
I'll be sending it for review after I've looked over it again.

Similarly, since earlier this year, we now also have ciphertext verification
tests in Android's VTS (Vendor Test Suite)
I'll be adding one for this new flag.

These ciphertext verification tests test the round-trip from the key added by
userspace to the data on-disk -- even if the data is encrypted by inline crypto
hardware rather than the kernel itself.  So they're better than Kunit tests.

The thing I'm struggling with a bit is actually that when inline crypto is used,
IV_INO_LBLK_32 introduces a case where the DUN can wrap from 0xffffffff to 0,
and that case is new/special in that blocks can't be merged over that boundary
even if they are both logically and physically contiguous.  So, we could also
use a test that tests doing I/O around this boundary where the DUN wraps around.

- Eric

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 20:41 Eric Biggers
2020-05-19 11:13 ` Theodore Y. Ts'o
2020-05-19 14:45   ` Eric Biggers [this message]
2020-05-19 16:33 ` Paul Crowley
2020-05-25 15:33 ` Eric Biggers

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200519144501.GA857@sol.localdomain \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Crypto Archive on

Archives are clonable:
	git clone --mirror linux-crypto/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-crypto linux-crypto/ \
	public-inbox-index linux-crypto

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone