Plans for adding cipher mode to file headers

Plans for adding cipher mode to file headers

[Will Morrison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To make the changes to store the cipher mode in the file header, we
are proposing the following.

1. Change ECRYPTFS_SUPPORTED_FILE_VERSION to 4. This should prevent
old versions of eCryptfs from trying to read new style headers.

2. Add a new cipher mode field in the appropriate packets of version 4
file headers. (I believe these are tag 1 and tag 3, for asymmetric and
symmetric keys). Since there is no equivalent to this field in the
OpenPGP RFCs, we will be creating a new list of constants similar to
the ones in ecryptfs.h for the mode type.

3. When reading a file header and initializing a crypt_stat, if the
version number is 4 or greater, read the mode out of the header,
otherwise, default to CBC.

4. When writing out headers, refer to the file_version field in the
crypt_stat to determine what to write out. If it's 4 or greater,
include the mode field.

This should result in the new version 4 header being written for all
new files. Old files would still be read and written with the version
3 headers and default to using CBC mode. Older versions of eCryptfs
should refuse to open files with version 4 headers.

Does this make sense? If not, what are we missing?

Thanks,
- -Will
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJRrqd0AAoJEH8zVN2+6bAcD3UP/3r/FuHfQv175nccZ+JOemZZ
65hn9zMi5dFVCTcvqBwMFWFymOKyOJLYM5yP2rX093JpIA3MgquN3yNgOiEd+adt
8hLKZ84KPMnA41m220ujOLvKD6UA4GQpSTwkDsbvYxQV9W3EuPsR65WtSt23uECj
VjU9EtKZ4xAQbQeXbRTTL678jIRUf4rffUEsFV/KWosdjeINNxZQPoZJHAwiTMDY
lemxgXnMmgr/fs/NnW6W+D9hBehIXUXrqlZ/f+EkFygXCafHOLS6f7JHuq5MNDeD
O5A53ClD2p6984sh745oUMltt0j0cQdF+gE//1hS1RhqHe2//K5YQe7Xgqab/Ahb
lsOdc2cDa8B+w6jITyPfn31CJdmS3o/o+ltavTmK2hnMJB773ibmoPG8q2EGUOnO
ePs6C9uCaBEV48svjlIrcWHE+NgbqK+cetyF5DP3mo1dPR+GiSPthEKrr0Tp96Ys
ECYHWq+6N+cJnzb1GKM0frRAZPgvSmxtRdNQSiH82Moz5ThUIYaS6buhLApBvBIR
TtDbL+hgZ8E90gcyeaPNTzmAmaVkj79F03HBq1GtkjesF78+AGmxL4xnUyJaV2s2
wc8xKvcwBctcHj+i2NoJq5dRX/8mGclA4sP18LPXqLxhyg3G13P/xZPtmdReRvpH
/pBAmFxFCl3rfQkqsZdp
=fnmV
-----END PGP SIGNATURE-----

Re: Plans for adding cipher mode to file headers

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

Sorry for not getting back to you sooner. I've been busy with other
things.

On 2013-06-04 22:50:28, Will Morrison wrote:
> To make the changes to store the cipher mode in the file header, we
> are proposing the following.
> 
> 1. Change ECRYPTFS_SUPPORTED_FILE_VERSION to 4. This should prevent
> old versions of eCryptfs from trying to read new style headers.
> 
> 2. Add a new cipher mode field in the appropriate packets of version 4
> file headers. (I believe these are tag 1 and tag 3, for asymmetric and
> symmetric keys). Since there is no equivalent to this field in the
> OpenPGP RFCs, we will be creating a new list of constants similar to
> the ones in ecryptfs.h for the mode type.
> 
> 3. When reading a file header and initializing a crypt_stat, if the
> version number is 4 or greater, read the mode out of the header,
> otherwise, default to CBC.
> 
> 4. When writing out headers, refer to the file_version field in the
> crypt_stat to determine what to write out. If it's 4 or greater,
> include the mode field.
> 
> This should result in the new version 4 header being written for all
> new files. Old files would still be read and written with the version
> 3 headers and default to using CBC mode. Older versions of eCryptfs
> should refuse to open files with version 4 headers.
> 
> Does this make sense? If not, what are we missing?

It makes sense, but I don't really like it. It prevents old kernels from
being able to open files created by newer kernels even when CBC is used
for the new files.

Breaking backwards compatibility should only be done for really good
reasons, when there's no other option.


I didn't want to shoot this idea down without proposing a solution of
my own, but I haven't had time to read back through the OpenPGP RFCs and
look at what other fields we have in our metadata.

The good news is that this shouldn't block you for the time being. You
can hardcode your new mount_crypt_stat and crypt_stat cipher mode fields
to GCM for now and then figure out how to dynamically set them later
when we come to a decision on the metadata format changes.

Tyler

> 
> Thanks,
> -Will

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Plans for adding cipher mode to file headers

[Will Morrison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We've been discussing what to do about back/forwards compatibility.
We've run into a few dead ends trying to figure it out, and the best
we've come up with is to special-case CBC encrypted files, and always
write out old style headers for those.

There are version fields in tag 1 and 3 packets, and we thought about
possibly writing out two packets, one for each version, but if a file
contains what it considers to be a malformed packet, it will not
continue looking for packets, and just avoid the file. Changing the
version in the packets would count as malformed for the current code.

The only way we can currently see of letting older versions read files
created by newer versions is to special-case CBC mode encryption, and
always write the current version headers (no cipher mode field, file
version 3) when encrypting with CBC. If encrypting with any other
mode, the new style headers would be written, since older eCryptfs
builds would not be able to read them anyway. This would add some
extra logic in the functions dealing with writing headers to handle
the special-casing. It would also require that the
ECRYPTFS_FILE_VERSION constant be used dynamically depending on what
the cipher mode was.

I don't know what is better, extra code paths that should be tested
and maintained, or a lack of forward compatibility between versions of
eCryptfs for files encrypted with CBC. Do you have any thoughts one
way or the other?

- -Will
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJRt/OdAAoJEH8zVN2+6bAcvXkP/1UqY82h7wl54Eiv//3XewrN
c4VByoYKwO28pbNz3JRSl9WEUHD9viji0aJdnnjx3aWYJ3OWc0IKSdsJpPYSnaHa
wXaohMD6MV0i20iFyPy15SMjdt1KcpEGyX4j3bhYvP+lObhhP5/jbF6sFa0RJdfI
qjF4ujPxAKdB111UOSZYzxmoC4ljowbMV/TBy1p61h98AR9tWvkck+2W/RLCIJ7G
H2la2h017dKMqnqSfgJSb5ATbDqH6fUfvn6+iof+ZbfGHQ7yU4aPbqcNCogZSBYt
CZ5d/Y46eo5KcX+0rHsVbXJg3ctV8zWdlMHAwdlvZrXepCnQXHccpm/GIQI2gChD
fyffsevnQRYreYqsjikF4z7h4WgsU0TUPsRGOpalmT3u72Hh9DPTKOw2SDRBTrSR
LFqlYnxL5vr6w0Qbm9VYjtqZz1XQWDalJM7OIHk7zllsMPufYcb1fawhhdeyYl4t
4hSsK4gitRsvbBhatvMXygvCIwrOgz4I4L0zsT6eymirzgf5FmVFxNCNiknDcV3/
qC20B0TsHnINiWq1XlpQGP80IhGnor1tKDA46SIbQukmoIicJAD7CDpLztsvj1qo
qbRO9kPYNXPVqsggll+axDmAsGmZV+8L2uPvj9Gy7reFIrzfaSidAzjuipTLx2RT
IjJnvbuOmy7Psng5Vtmd
=HBO0
-----END PGP SIGNATURE-----