Re: Changing salt value

[Tyler Hicks <tyhicks@canonical.com>]

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

On 2015-02-11 13:50:08, Sylvain Pelissier wrote:
> 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.

I thought about doing that but it doesn't match the current syntax of
the wrapped-passphrase file.

I think we'll have to do something a little different and introduce
versioning into the file. Stay tuned.

Tyler

> 
> On 10 February 2015 at 23:44, Tyler Hicks <tyhicks@canonical.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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