lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 24 Aug 2020 11:21:14 -0700
From:   Eric Biggers <>
To:     Jeff Layton <>
Subject: Re: [RFC PATCH 1/8] fscrypt: add fscrypt_prepare_new_inode() and

On Mon, Aug 24, 2020 at 12:48:48PM -0400, Jeff Layton wrote:
> > +void fscrypt_hash_inode_number(struct fscrypt_info *ci,
> > +			       const struct fscrypt_master_key *mk)
> > +{
> > +	WARN_ON(ci->ci_inode->i_ino == 0);
> > +	WARN_ON(!mk->mk_ino_hash_key_initialized);
> > +
> > +	ci->ci_hashed_ino = (u32)siphash_1u64(ci->ci_inode->i_ino,
> > +					      &mk->mk_ino_hash_key);
> i_ino is an unsigned long. Will this produce a consistent results on
> arches with 32 and 64 bit long values? I think it'd be nice to ensure
> that we can access an encrypted directory created on a 32-bit host from
> (e.g.) a 64-bit host.

The result is the same regardless of word size and endianness.
siphash_1u64(v, k) is equivalent to:

	__le64 x = cpu_to_le64(v);
	siphash(&x, 8, k);

> It may be better to base this on something besides i_ino

This code that hashes the inode number is only used when userspace used
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 for the directory.  IV_INO_LBLK_32 modifies
the encryption to be optimized for eMMC inline encryption hardware.  For more
details, see commit e3b1078bedd3 which added this feature.

We actually could have hashed the file nonce instead of the inode number.  But I
wanted to make the eMMC-optimized format similar to IV_INO_LBLK_64, which is the
format optimized for UFS inline encryption hardware.

Both of these flags have very specific use cases; they make it feasible to use
inline encryption hardware
that only supports a small number of keyslots and that limits the IV length.

You don't need to worry about these flags at all for ceph, since there won't be
any use case to use them on ceph, and ceph won't be declaring support for them.

- Eric

Powered by blists - more mailing lists