Re: [PATCH] ext4: reserve codepoints used by the ext4 encryption feature

[Michael Halcrow <mhalcrow@google.com>]

On Fri, Jan 23, 2015 at 11:41:25AM -0800, Darrick J. Wong wrote:
> On Fri, Jan 23, 2015 at 02:36:21PM -0500, Theodore Ts'o wrote:
> > +/* Encryption algorithms */
> > +#define EXT4_ENCRYPTION_MODE_INVALID		0
> > +#define EXT4_ENCRYPTION_MODE_AES_256_XTS	1
> > +#define EXT4_ENCRYPTION_MODE_AES_256_GCM	2
> > +#define EXT4_ENCRYPTION_MODE_AES_256_CBC	3
> > +
> >  /*
> >   * Structure of the super block
> >   */
> > @@ -1156,7 +1163,8 @@ struct ext4_super_block {
> >  	__le32	s_grp_quota_inum;	/* inode for tracking group quota */
> >  	__le32	s_overhead_clusters;	/* overhead blocks/clusters in fs */
> >  	__le32	s_backup_bgs[2];	/* groups with sparse_super2 SBs */
> > -	__le32	s_reserved[106];	/* Padding to the end of the block */
> > +	__u8	s_encrypt_algos[4];	/* Encryption algorithms in use  */
> 
> Does this imply that one can have up to 4 algorithms in use at once?

For now. But that may be more in the future. According to what's
in-plan, the data contents may be protected with XTS or
GCM. Encryption happens on a per-file basis, so several different
files may be encrypted with several different modes in the same
volume. The file names are protected with CBC.

It's possible that we may want to add an integrity-only mode down the
road, such as HMAC-SHA1. Or when the CAESAR competition yields some
promising modes, we may want to use one of them.