Comment 15 for bug 259631

Thank you for your response, I will test this shortly.

Please not that the output I posted is not the complete output of the unwrap
command.

In any case, is it possible to take the mount_passphrase and reverse it in
order to compare it to the original login_passphrase ? Or can one
mount_passphrase be generated from different login passwords ?

Rune

2008/10/21 Dustin Kirkland <email address hidden>

> Rune-
>
> That "fa....5c" value is your *mount* passphrase, which you have just
> published to the internet. Consider any data there compromised.
>
> Guys-
>
> There are 2 passphrases involved.
> 1) There's your login_passphrase (what you use to login to the system)
> 2) And there's your mount_passphrase (what is used to mount the ~/Private
> directory and encrypt/decrypt the data there)
>
> When you successfully login to your system, a PAM module in the
> authentication stack called pam_ecryptfs takes your login_passphrase,
> and uses that to decrypt a file, ~/.ecryptfs/wrapped-passphrase, which
> contains your mount_passphrase.
>
> If that file is successfully decrypted, your decrypted mount_passphrase
> will be inserted into your kernel keyring.
>
> Then, pam_ecryptfs will attempt to run /sbin/mount.ecryptfs_private,
> which will try to mount your ~/Private directory using the passphrase
> which was added to the keyring. If the mount_passphrase not able to be
> retrieved and added to the kernel keyring, you will get the
> "keyctl_search: Required key not available" error.
>
> This is what should happen automatically.
>
> To find out where the problem is, you can perform each of these steps
> manually.
>
> First, you need to figure out if you can decrypt your mount_passphrase,
> using 'ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
> LOGIN_PASSPHRASE'. You will probably get the salt warning, and then if
> it succeeds, it will print the mount_passphrase to the screen. When you
> ran ecryptfs-setup-private, you were able to either choose your own
> mount_passphrase or have one generated for you. If you had one
> generated for you, it would be 128-bits of random data, represented by a
> string of hexadecimal digits. In any case, if ecryptfs-unwrap-
> passphrase is able to print it to screen, that's good. Check the exit
> code (echo $?) immediately after running ecryptfs-unwrap-passphrase, and
> ensure that it's 0. Otherwise, your wrapped-passphrase file is probably
> encrypted using a different password than the one you supplied.
>
> Once you're able to successfully decrypt ~/.ecryptfs/wrapped-passphrase
> (and please don't post your passphrases here), run
> 'ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-
> passphrase LOGIN_PASSPHRASE'. This will add the passphrase to the
> kernel keyring. You can list the id's of the keys in the keyring using:
> 'keyctl show'. Note that you might need to install the 'keyutils'
> package.
>
> Now that you have the passphrase in the keyring, you should be able to
> mount your encrypted private directory with 'mount.ecryptfs_private'.
>
> If you're still getting "keyctl_search: Required key not available",
> then the wrong passphrase has been inserted into your keyring. You can
> check what key mount.ecryptfs_private expects with 'cat
> ~/.ecryptfs/Private.sig'. This "signature" should match the signature
> of the key in your keyring, as shown by 'keyctl show'.
>
> I would very much appreciate it if the people on this bug experiencing
> this problem could walk through these steps and please tell me where you
> are experiencing the failure.
>
> :-Dustin
>
> ** Changed in: ecryptfs-utils (Ubuntu)
> Assignee: (unassigned) => Dustin Kirkland (kirkland)
> Status: Invalid => Incomplete
>
> --
> Cannot open Private directory after a reboot
> https://bugs.launchpad.net/bugs/259631
> You received this bug notification because you are a direct subscriber
> of the bug.
>