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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
