Improve record-your-passphrase dialog

This should only pop-up if you're configured to use an encrypted $HOME or encrypted $HOME/Private directory.

Are you sure that you're not configured to do so?

When you're logged in, what is the output of the 'mount | grep ecryptfs' command?

Do you have a ~/.ecryptfs directory?

:-Dustin

Maybe I did choose to encrypt the fs. But my concern, and the reason for this bug, is that the pop-up confused me. It was not clear what the purpose was. Is this asking for my user password? Or is it asking for a master key that I can use to decrypt my directory in the event of OS failure? If so, it would be good to confirm the password twice rather than once.

======================
$ mount | grep ecryptfs
/home/[username]/.Private on /home/[username] type ecryptfs (ecryptfs_sig=cc21271a0.......,ecryptfs_fnek_sig=c72a126b8.......,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

$ ls -aFl | grep ecryptfs
lrwxrwxrwx 1 [username] [username] 104 2009-02-08 10:10 .ecryptfs -> /var/lib/ecryptfs/[username]/
======================

So I attempted to run the command by hand, and it appears to be failing. I tried my user login password, and also tried the passphrase that I had used in the initial pop-up box above:

$ ecryptfs-unwrap-passphrase .ecryptfs
Passphrase: [password]
Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Error: Unwrapping passphrase failed [-5]
Info: Check the system log for more information from libecryptfs

/var/log/syslog:
Apr 14 06:48:13 [hostname] ecryptfs-unwrap-passphrase: Error attempting to read encrypted passphrase from file [.ecryptfs]; size = [4294967295]

According to that mount entry, you absolutely do have an encrypted
home directory.

If you want to run the command by hand, you should run this:

 $ ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase

You are entering your system login passphrase at this point, and if
you enter that correctly, it will respond with your mount passphrase.

:-Dustin

ok thanks for clearing it up. I think it was just unexpected, and I didn't understand the whole interaction with the 'run this action now' terminal window.

Marking wishlist, and targeting at Karmic.

We should improve the record-your-passphrase dialog to be a bit more intuitive.

:-Dustin

I just had this today...

It also got me really confused.

The popup clearly says:
-----
Please print or write it down and store it in a safe location. You can run the "ecryptfs-unwrap-passphrase" command now to do this. Enter your user password at the "Passphrase" prompt.
-----

So I did...
-----
$ ecryptfs-unwrap-passphrase
Passphrase: [password]
Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Error: Unwrapping passphrase failed [-5]
Info: Check the system log for more information from libecryptfs
-----

It should be clearly indicated the command to run is:
-----
ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase
-----

When that dialogue popped up for me after booting my freshly installed Jaunty with encrypted LVM, I ran into a problem similar to François's (Hi, btw):

-------------------------------
~$ ecryptfs-unwrap-passphrase
Usage:
ecryptfs-unwrap-passphrase [file]
or
printf "%s" "wrapping passphrase" | ecryptfs-unwrap-passphrase [file] -
-------------------------------

Looks like it didn't find it's way to ~/.ecryptfs/wrapped-passphrase by default, where the file actually was.

Committed revision 391.

Does your commit fix that path issue as well?

Martin-

I don't understand your question ...

I changed the ecryptfs-unwrap-passphrase binary. If zero arguments
are passed, it looks for a file called
$HOME/.ecryptfs/wrapped-passphrase. If this file exists, then it will
prompt you for a passphrase to decrypt this file.

If that file does not exist, the usage statement is printed.

I think this should be more user-friendly.

:-Dustin

This bug was fixed in the package ecryptfs-utils - 75-0ubuntu1

---------------
ecryptfs-utils (75-0ubuntu1) karmic; urgency=low

  [ Dustin Kirkland ]
  * debian/rules: drop hackery that moves stuff /usr/share/ecryptfs-utils
  * src/utils/mount.ecryptfs_private.c: update inline documentation
  * debian/changelog, src/libecryptfs/cmd_ln_parser.c,
    src/libecryptfs/key_management.c, src/pam_ecryptfs/pam_ecryptfs.c,
    src/utils/ecryptfs_add_passphrase.c,
    src/utils/ecryptfs_insert_wrapped_passphrase_into_keyring.c,
    src/utils/ecryptfs_rewrap_passphrase.c,
    src/utils/ecryptfs_unwrap_passphrase.c,
    src/utils/ecryptfs_wrap_passphrase.c: silence some useless logging,
    LP: #313330
  * include/ecryptfs.h, libecryptfs/key_management.c,
    utils/ecryptfs_insert_wrapped_passphrase_into_keyring.c,
    utils/ecryptfs_unwrap_passphrase.c: if the file to unwrap is
    unspecified, try to use the default ~/.ecryptfs/wrapped-passphrase
    before bailing out, LP: #359997
  * src/utils/ecryptfs-setup-private: unix_chkpwd is not always present
    (eg, gentoo), LP: #332341

  [ Tyler Hicks ]
  * doc/manpage/ecryptfs.7: ecryptfs_encrypted_view option desription
    was wrong LP: #328761

  [ Michal Hlavinka ]
  * decision_graph.c: fix uninitialized return code
  * mount.ecryptfs.c: don't pass verbosity option to kernel

  [ anrxc & Dustin Kirkland ]
  * doc/Makefile.am, src/desktop/Makefile.am: fix automake installation from
    /usr/share to /usr/share/ecryptfs-utils

  [ Daniel Baumann & Dustin Kirkland ]
  * debian/rules, debian/control: sync differences between Debian & Ubuntu's
    packaging

  [ Arfrever Frehtes Taifersar Arahesis ]
  * src/key_mod/ecryptfs_key_mod_gpg.c,
    src/key_mod/ecryptfs_key_mod_pkcs11_helper.c: fix implicit declations

  [ Frédéric Guihéry ]
  * key_mod/ecryptfs_key_mod_tspi.c, utils/ecryptfs_generate_tpm_key.c:
    the SRK password should be set to 20 bytes of NULL (wellknown
    password), in order for different tools to request key protection
    with the Storage Root Key

 -- Dustin Kirkland <email address hidden> Sat, 02 May 2009 11:44:56 -0500

You don't mention that you've added passphrase confirmation above. Is there a separate bug for this? Not doing so is an accident waiting to happen.

agreed. My passphrase is generally 20+ characters, and if I'm understanding this, a typo here renders my data gone :-O
Heck - I'd be OK with THREE confirmations for something this paramount.

Filed bug 495339 for the issue of passphrase confirmation.

It sounds like many people are making the same mistake I did: they read the dialog, and believe that they are being ASKED for a passphrase that will be used to encrypt their home folder. In fact, that password has ALREADY BEEN MADE, and this is merely giving you the opportunity to VIEW that password so that you can record it for safekeeping.

There are two factors that contribute to this impression:

1) the dialog opens with "To encrypt your home directory or "Private" folder" - the use of the word "to" at the beginning of the sentence implies future tense- ie, the user believes that this is an action which is ABOUT to occur, not one that has occurred already.

2) in the dialog, reference is made to "your user password", but after clicking the button, the screen reads "Passphrase:", which further implies that the user is ENTERING a passphrase that will be used for encryption.

Yes, the dialog box does say "Enter your user password at the "Passphrase" prompt.", but as a rule, people speed-read dialog boxes, and so the overall impression can easily be the one many users have expressed here.

I know that I believed I was being asked for a passphrase, which i picked out, dutifully wrote down and then entered. I was shocked that I was only asked for it once- normally you're required to enter a new password twice to eliminate spelling errors. I received an error message, but I thought that there was an error with the program, and that I'd need to track the bug down later, but I didn't need to rush. After all, since my files hadn't been encrypted yet, I could take care of this at my leisure.

SUGGESTED FIX:

I'd suggest something that puts people in the right frame of mind from the outset, a la:

********************************************
Congratulations! Your home directory has been encrypted, and your personal data is secure in the event of theft or loss. Usually your directory is unlocked with your user password, but if you ever need to manually recover this directory, you will need this passphrase. Please print or write it down and store it in a safe location.

To see your passphrase now, click the button below. You will be required to enter your login password. If you need to record your passphrase in the future, just run the "ecryptfs-unwrap-passphrase" command in a terminal.
=======================
See my passphrase now | Close without viewing passphrase |
=======================
*******************************************

I suggest that a change should be made to the "ecryptfs-unwrap-passphrase" command so that it requests "Password for $USER". If an incorrect password is given, it should say "Sorry, try again". This is the expected behavior based on invoking sudo, and it's going to confuse the user to switch behavior on them.

Hi Dustin,

I'm a Ubuntu novice to please be easy on me.

I believe I am having the same issue as described here after inadvertently setting a passphrase and not recording in.

I was in the process of changing my password when this happened so I hope this hasn't made matters worse.

When I restart, I now get

>> Could not update ICEauthority file / home/darren/.ICEauthority
>> There is a problem with the configuration server. (/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256)
>> Nautilus could not create the following required folders: /home/darren/desktop, / home/darren/.nautilus

I then get the Record your encryption passphrase screen and I enter my logon password and the screen and it sits there.

I'm now left with no desktop. I have accessed the terminal screen to run your suggestions via terminal and i get this

>> keyctl_search: Required key not available
>>Perhaps try the interactive 'ecryptfs-mount-private'

I run it and get

>> Error: Uwrapping passphrase and inserting into the user session keyring failed [-5]
>> Info: Check the system log for more information from libecryptfs
>> Error: Your passphrase is incorrect

I then followed step in #3 above and now get this

>> Error: Unwrapping passphrase failed [-5]
>> Info: Check the system log for more information from libecryptfs

and don't know where to go now.

Help please.

Just want to cast my vote for PhysicsDan's phrasing in comment #15. I think that makes it crystal clear, which is a *good thing* when encrypting personal files.

Darren,

This link helped me with the same issue you are experiencing.

https://answers.launchpad.net/ubuntu/+question/85598

The reason I am looking at this bug is I tool the steps in #18 to fix Ubuntu.

I finally was able to log back in.

My happiness soon faded when I realized that my home folder's contents (the contents that was in the folder before I did the steps in #18) was now encrypted. Two files suggest how to open the encrypted files.

Access-Your-Private-Data.desktop

README.txt

In the 'Access-Your-Private-Data.desktop' file it says:

"THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA.

From the graphical desktop, click on:
 "Access Your Private Data"

or

From the command line, run:
 ecryptfs-mount-private"

it drops to:
>

What do I do next?

update

root@progone:/home/matthew# ecryptfs-mount-private
ERROR: Encrypted private directory is not setup properly

Progone / Darren:
This is a bug report intended to clarify the text presented to the user. Please limit your discussion to this topic. I suggest searching the forums or creating a new forum post to discuss the problems you are experiencing,

Please add a link here to point to your forum post so others who stumble upon this bug in a search may benifit from your experience.
Thanks,
Mike

Just performed a fresh install of 10.04 (which I believe ran an update during the installation process) and was still confronted with the poorly-written message at the top of this page. Is the "fix released" just for future releases, or was it supposed to be applied during the installation process?

Just for clarification, the definition here clarifies where the confusion came from for me:
http://en.wikipedia.org/wiki/Passphrase#Compared_to_passwords

"Passphrases differ from passwords. A password is usually short — six to ten characters..."
"Passphrases are generally stronger, ... 20 to 30 characters or more is typical"

The second dialog says to "enter your passphrase". Simply changing that to read "enter your password" would have prevented this entire bug report for me.