How Encrypted-Home + eCryptfs Works

March 1, 2009

One comment to my last post, Jaunty Encrypted Home Directories, deserves a blog post of its own to answer..

gotgenes said…

Very cool. So does this mean there’s now a separation of a user’s password from the user’s decryption password? This was an issue brought up in your previous post–oftentimes we want our encrypted data passphrase to be significantly longer than our user passphrase.

Yes. And we provided that same separation in Intrepid as well. Let me explain in better detail how this feature works…

When you login, the pam_ecryptfs module takes your login passphrase (which is usually pretty short, and easy to remember), and symmetrically decrypts the file ~/.ecryptfs/wrapped-passphrase, which will yield your mount passphrase.

Your mount passphrase is a randomly generated 128-bit key. This is very hard to remember, and rather hard to guess. 2^128 is a big number!

unique passphrases

This mount passphrase is salted, hashed 65536 times using sha512 (i.e. key strengthened), and loaded into your kernel keyring. In eCryptfs terms, the salted, hashed passphrase is your “file encryption key, encryption key“, or fekek.

New for Jaunty (and the upstream 2.6.29 kernel), we have encrypted filenames too. In this case, the mount passphrase is salted with a different value, hashed 65536 times using sha512, and also loaded into your kernel keyring. This second key is your “filename encryption key“, or fnek.

Now, every time the kernel encounters an encrypted filename in your encrypted home directory, it is decrypted using your fnek and presented to you in plaintext.

To read/write encrypted data from/to a file, your fekek is used to decrypt the “file encryption key“, or fek, which is embedded in the header of the file. This embedded fek is unique per file! This means that two files, with the exact same contents, will produce two completely different encrypted files, which helps thwart known-plaintext attacks.

Does that explanation help?


23 Responses to “How Encrypted-Home + eCryptfs Works”

  1. aigarius Says:

    How about logging in without mounting the encrypted folder?

    How about plausible denyability mounting? (Mounting with an alternative password to show another set of files)

    Ideally one should be able to use one of multiple passwords to open multiple file storage areas and there would be no way to determine how many areas there are without having all the passwords.

  2. Says:

    Am I reading this right that it is your login password that protects the wrapped-passphrase?

    If so we are still at a place where a short passphrase protects the long one.

  3. Dustin Kirkland Says:


    Two-factor authentication involves:
    1) something you have
    2) something you know


    In this case, your login passphrase is something you know.

    And your ~/.wrapped-passphrase file is something you have.

    Some eCryptfs users increase the overall security of their system by storing their wrapped-passphrase file on some removable media, such as a USB key.


  4. Dustin Kirkland Says:


    If you want to log in without mounting your entire encrypted home directory, I suggest that you look at eCryptfs encrypted-private support. You can setup your system to only encrypt data in ~/Private, and you can configure whether you want it automatically mounted on login.

    eCryptfs does not currently support plausible deniability.


  5. Roger Binns Says:

    The biggest problem I have with these schemes is that they only work with password authentication. My laptop (ThinkPad T61) has a fingerprint reader so I can login using that, but then it provides no way of doing the encrypted home directory other than also demanding a password, defeating the purpose of the fingerprint authentication. (And just to make life even more fun, thinkfinger stores the fingerprint data in your home directory!)

    The whole Gnome keyring insisting on a password was a pain for a long time until they allowed empty passwords.

  6. Dustin Kirkland Says:

    Hi Roger-

    Please see:

    The prevailing opinion from security professionals is that fingerprints are perhaps a good replacement for usernames. However, they’re really not a good replacement for passwords.

    Consider your laptop… How many fingerprints of yours are there on your laptop right now? As such, it’s about as secret as your username. You don’t leave your password on your spacebar, or on your beer bottle 🙂

    This wikipedia entry (although it’s about Microsoft Fingerprint Readers) is pretty accurate:


  7. Says:

    Dustin, let me start this post saying that I have not delved deeply into eCryptfs. I may be missing something that is covered elsewhere more in depth than the reading I have done on the topic. Here’s what I don’t understand about your argument.

    What I have (~/.wrapped-passphrase) is protected by what I know (login password).

    How is gotgenes’ premise that the encrypted data is not separated from the login password? Yes I can put the key on a thumbdrive but I’d argue that most users are not going to do this considering the small percentage that will use encryption for their data to begin with. At the end of the day the 128-bit key is still protected with a [arguably] weaker key, the login passphrase [short, easy to remember].

    What is the difficulty of offering an option to protect the 128-bit key with a different passphrase from what you use to login?

  8. DidRocks Says:

    Hi Dustin,

    I remebered you exlained that one of the biggest issue for you in the intrepid version to encrypt whole home directory is that the passphrase is in ~/.wrapped-passphrase.

    From your previous comment, it seems to be still the case. So, how do you do? Do you put an exception to not encrypt this specific file and have it accessible, even when ~ is not decrypted yet?

  9. meastp Says:


    If you had a backup of the .wrapped-passphrase on removable media, perhaps you could have an option to delete the .wrapped-passphrase file stored on your computer if the login passphrase is entered incorrectly x times?

    Would that improve security if the computer is stolen? Or do you need the correct login passphrase to be able to delete .wrapped-passphrase?

  10. Dustin Kirkland Says:


    Sure, please see the manpage ecryptfs-setup-private(1):

    Refer to the -w, –wrapping option:
    -w, –wrapping
    Use an independent wrapping
    passphrase, different from the
    login passphrase

    You can certainly set it up this way. But this will not be the Ubuntu-default mechanism.


  11. Dustin Kirkland Says:


    Great question!

    In both your mounted, and unmount home directory, $HOME/.ecryptfs is a symbolic link to /var/lib/ecryptfs/$USER

    As such, this is where your wrapped-passphrase actually lives.

    In my case, where I want to improve the strength of my 2-factor authentication, /var/lib/ecryptfs/$USER is actually another symlink to some removable media.


  12. Dustin Kirkland Says:


    Perhaps, but I don’t think you would be able to increase the overall security of the system.

    If that person has acquired your laptop, and has access to the wrapped-passphrase, the first they would do is copy that file to another computer that doesn’t have the self-destruct mechanism.

    Basically, there’s no way to enforce such a system.


  13. meastp Says:

    Ah, I didn’t think of that. The thief would need to know how the feature works, though, but all the info is on your blog, isn’t it? 😉

    An integrated tool / option to move the .wrapped-passphrase -file to a usb-stick and make this symbolic link, or move it back from a usb-stick to the system might be a nice feature. And a warning on first boot to backup this file on external media, and a tool to do so.

  14. gotgenes Says:


    Thanks a lot for taking the time to make this post. I do find the concept clearer now. I guess I have a similar question to Chuck Frain with regards to the safety of my encrypted information.

    If I use the alternate installer and do encryption via LUKS and LVM, then I’m prompted with a password before my system can even mount my home directory. I make this password (which I’ll call my data access password) extremely long–at the limits of what I can remember, because it makes brute force guessing of this data access password unreasonably long. My user login password, however, is shorter; something I’m sure to remember, and something which I’m comfortable changing from time to time.

    The way this is, it’s okay if someone steals my laptop (well, it isn’t for me, but for the safety of my data). They will have to brute force the data access password to even get to my files.

    Now let’s talk about the new eCryptfs arrangement. My data access password is still required to get to my data. Now instead of entering that actual password, however, I have the convenience of having that password “unwrapped” if I can recall my user login password. Am I understanding your post correctly?

    If so, then my data is much closer to being obtained. My shorter user login password length makes brute-force guessing more possible, and once the attacker has cracked my user login password, they can unwrap the data access password, and get access to my data. That doesn’t sound very appealing.

  15. Dustin Kirkland Says:


    If these are your concerns, I consider you implement the suggestions I have in the 2-factor Authentication post:



  16. Says:

    Hi Dustin,

    Thanks for your time on answering questions on this and clarifying some of these issues we’re asking about.

    I have another question for you on the passphrase. If I set this up under a default installation of Ubuntu what is the mechanism to change the passphrase for my .wrapped-passphrase to make it unique and separate from the login password after it has been set initially?

  17. Dustin Kirkland Says:


    You can re-wrap your wrapped-passphrase with:
    $ ecryptfs-rewrap-passphrase $HOME/.ecryptfs/wrapped-passphrase

    Note that this will break automatic mounting your encrypted-private and encrypted-home upon login.

    Thus, you can do this for an encrypted-private directory and mount it manually after-the-fact, but you cannot do this for an encrypted-home. You won’t be able to login to the system.


  18. JanHolbo Says:

    I do not know if this is a wrong place to post but I have tried googling without a solution.

    I am using Ubuntu 9.04 (Jaunty). I have a /home partition with an encrypted user folder. My problem is that I lost the root partition and thus the .sig and wrapped passphrase files. I do remember the passphrase.

    I have been able to mount the encrypted folder and can read the contents of at least some of the files. But! the filenames are still encrypted.

    Any help on this?

  19. JanHolbo Says:

    I still have my files locked into the ecrptfs. And I have discovered that the few files I have been able to decrypt was from one of my attempts. So I am still in tourble with these files.

    I think I know what the problem is might be though – the salt value might give a different key/sig. Now my question is: is it possible to ‘brute force’ my way through different key values to find the right one that will create my signature that will unlock my files. I still have my passphrase remembered.

    Thanks in advance!

  20. Dustin Kirkland Says:

    A salt wouldn’t be worth much, if you could brute force it.

    See ecryptfs-utils/src/include/ecryptfs.h:

    #define ECRYPTFS_SALT_SIZE 8
    #define ECRYPTFS_DEFAULT_SALT_HEX “0011223344556677”
    #define ECRYPTFS_DEFAULT_SALT_FNEK_HEX “9988776655443322”

    So that 16 hex digits, 16^16, which is pretty big.

    By my calculations, if you try 1000 salts per second, it would take you 585 million years in the worst case to crack it.


  21. Alexander T Says:

    Hi Dustin,
    just to make to clear: is generated passphrase everything I need to decrypt my data from .Private folder (including file names)?
    What about salt? It is said in this blog that the passphrase is salted before being hashed. Where is that salt got from? Is it somehow derived from the passphrase? And there are two salts, one for fekek and another one for fnek. Where do I get them from? My point is that if it can be derived from passphrase, than that salt doesn’t improve security, as anyone can get it. If not, then the passphrase isn’t the only thing needed to know.

    And one more question:
    I have been playing and trying to decrypt my .Private home folder from the different user account (to test it if I could recover data in case of need, using only .Private directory and passphrase, without .ecryptfs config files). And I was trying to do it using “mount -t ecryptfs” command (so I can choose the source and destination locations). I succeeded decrypting the files, but, however, I couldn’t decrypt the file names (even when I also typed “ecryptfs-add-passphrase –fnek” before mounting).
    Does it has to do anything with salt for fnek, which is different from the salt for fekek?

    You gave an advice on accessing encrypted data from Jaunty LiveCD in another blog, but if I understood correctly, it assumes having /dev folder together with /home folder on that device (so it is root partition, not just home).

  22. csavery Says:

    Hi Dustin,
    I have a question that I wonder if your experience can answer.
    I am looking at converting my current home to an encrypted one. I have a tutorial that should work for this. My one concern is that I have a very large .Virtualbox directory containing filesystems used by VirtualBox and I don’t really want to have that included in the encrypted home. I thought I could move it elsewhere and add a symlink to my home to locate it.

    So I’m wondering if a symlink is made in home after mounted will the encryptfs know that it’s a link outside the encryption and just handle it transparently or is it going to mess up and think it should be encrypted too? I general how are symlinks like this handled?

    Thanks for any input you may have.

  23. Dustin Kirkland Says:

    Symlinks will work as you desire for this case. If ~/.virtualbox is a symlink to, say /tmp, then data written to ~/.virtualbox will not be encrypted.

    It’s really simple enough to test. Just make ~/.foo a symlink to /tmp and write some files.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: