Thank you for you answer. It makes sense to have the salt value in the same file as the wrraped key because has soon has the salt value is lost then the key can not be unwrapped any more. Did you plan to keep the same syntax: satl=<salt value> At the end or begining of the wrapped-passphrase file ? This could help to detect the version of the wrapping tool used. On 10 February 2015 at 23:44, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> wrote: > On 2015-02-10 10:04:07, Sylvain Pelissier wrote: >> Hi, >> >> I am trying to change the default salt value used by ecryptfs-utils to >> wrapped the encryption key stored in >> "/home/.ecryptfs/user/.ecryptfs/wrapped-passphrase". I'm using Ubuntu >> 14.04 with the complete home folder encryption. I created a file >> .ecryptfsrc in the unencrypted home folder of the user which contains: >> >> salt=04ae48987b177f01 >> >> Then I wrap the passphrase key with the tool >> ecryptfs-unwrap-passphrase, I noticed that the result has changed and >> thus I think it uses the new salt value. However, when I replace the >> file /home/.ecryptfs/user/.ecryptfs/wrapped-passphrase with the new >> one, then when I log with the user credential I have the error telling >> that the key is not in the kernel keyring. >> Did I miss something ? > > Hi Slyvain - Using the .ecryptfsrc file with the encrypted home tools > (ecryptfs-setup-private, ecryptfs-wrap-passphrase, > ecryptfs-unwrap-passphrase, mount.ecryptfs_private, etc.,) is not > recommended. > > I recognize that ecryptfs_read_salt_hex_from_rc() is called from most of > those tools. However, I think that those call sites are incorrect in > doing so and I'd like to eventually remove those calls. > > There is an unfortunate difference of usage and configuration in the > mount.ecryptfs helper and the mount.ecryptfs_private helper. The > .ecryptfsrc file is something that *should* be specific to the > mount.ecryptfs mount helper so attempting to specify a salt in that file > would be incorrect for the mount.ecryptfs_private helper. > > That means that there is currently not a way to specify a non-default > salt value for use with the encrypted home tools. > > Dustin and I have been discussing this today. The current plan is that > we will implement a "version 2" of the wrapped-passphrase file. It will > contain a randomly generated salt value. Storing the salt outside of the > wrapped-passphrase file, such as in the .ecryptfsrc, would greatly > increase the chance that a user may migrate their wrapped-passphrase > file to another machine (for example, while upgrading to a new laptop) > but forget to migrate their .ecryptfsrc file. We want to include the > salt value in the wrapped-passphrase file to reduce the chances of data > loss those types of situations. > > Additionally, the ecryptfs_unwrap_passphrase() function will be modified > to automatically migrate salt-less, "version 1" wrapped-passphrase files > to the new "version 2" format and the file will be rewrapped with the > new key. By doing this migration in ecryptfs_unwrap_passphrase(), it > means that users will only need to log in through PAM and the > pam_ecryptfs module will be able to trigger the migration. > > We're working on this now. Thanks for bring this issue to our attention. > > Tyler -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
