Changing salt value

Changing salt value

[Sylvain Pelissier]

 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 ?

Sylvain

Re: Changing salt value

[Tyler Hicks]

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

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

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

Re: Changing salt value

[Sylvain Pelissier]

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

Re: Changing salt value

[Tyler Hicks]

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