Plans for adding cipher mode to file headers

-----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-----

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

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

-----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-----