Encrypted $HOME Now Offerred at Installation

September 5, 2009

I’m pleased to announce that the Ubuntu Karmic Alpha5 image now offers home directory encryption as an option to all installing users!

We introduced Encrypted Private Directories in the Ubuntu 8.10 release, using eCryptfs (an enterprise cryptographic filesystem in the Linux kernel) on $HOME/Private. This release helped “prove” eCryptfs, and helped us identify and fix a number of issues. This new approach to encrypted private data in Ubuntu provided a safe folder where users could store confidential information, automatically mounted at login, and unmounted at logout.

In Ubuntu 9.04, we retained the Encrypted Private Directory feature, but additionally offered Encrypted Home Directories to advanced users, through the alternate installer and a special boot parameter. This release generated quite a bit of interest in the feature and a healthy user community. Many, many thanks to the Ubuntu users and developers who used this feature, helping to file and fix bugs along the way.

So far in Ubuntu 9.10, we have:

  • fixed a number of bugs and usability issues (changelog)
  • provided AppArmor rules
  • enabled the shell scripts for localization/translations
  • and most importantly, set up encrypted swap in the installer if you enable home directory encryption

I believe Ubuntu now provides the most user-friendly personal data encryption solution in the industry.

So secure your data in Ubuntu! Get those Karmic home directories encrypted!


p.s. I authored an article for Linux Magazine that should be published in an upcoming issue discussing the technology in much greater detail. Stay tuned!


60 Responses to “Encrypted $HOME Now Offerred at Installation”

  1. dylanmccall Says:

    Out of curiosity, do you happen to know the performance hit home directory encryption has? You’ve suddenly made me really interested šŸ™‚

  2. Jef Spaleta Says:


    How does autologin in gdm interact with ecrypted home directory feature? Does autologin stop and ask you for the de-encryption key if encrypted home is enabled? Also do you know what the decryption/mount time penalty is from a boot to idle desktop perspect?

    I ask because the 10 second boot performance target for Karmic+1 which has been widely publicized specifically mentions autologin but doesn’t mention encrypted home so I thought its worthwhile to make sure you talk to that scenario and calibrate expectations before drive-by reviewers turn on encrypted home looking for 10 second boot times and not finding them because of a password dialog or due to the additional time delay that is outside of the target specification for fast boot.

  3. Tomasz Says:

    Thanks. I was waiting for this. Hopefully it also works with manual partitioning, where I have my own /home and swap partitions already set up. Or is that not possible (non-destructive for /home)?

  4. Dustin Kirkland Says:


    In most workloads, the performance penalty is under 5%. Phoronix has published studies on eCryptfs in the past. I’ll ping Michael Larabel and ask for a new one on Karmic.


  5. Dustin Kirkland Says:


    If you want to migrate to an encrypted home directory, you will want to follow the instructions I’ve previously published at:
    * http://blog.dustinkirkland.com/2009/06/migrating-to-encrypted-home-directory.html

    As for manual partitioning, that should not affect eCryptfs. I do strongly recommend you encrypt your swap space, if you’re manually configuring swap.


  6. Dustin Kirkland Says:


    Auto-Login and Encrypted-Home are incompatible features. See the screenshot above, where a radio button was cleverly chosen to allow one of:
    * Log in automatically
    * Require a password to log in
    * Require a password to log in and decrypt home

    Auto-login is intended for systems where data security is of a lower priority than quick access to the internet. I set up my mom’s laptop, for instance, with Ubuntu and Auto-login. However, I also configured an Encrypted-Private directory, where she stores her most sensitive documents. This way, she can quickly boot her computer and get on the internet. When she needs access to her Private data, she enters a password and her $HOME/Private directory is mounted at that time.

    An Encrypted Home might add a second or two (plus the password prompt) to a normal Ubuntu boot. Encrypted Home directories are most certainly *not* part of Karmic+1’s 10-second boot target.


  7. Jef Spaleta Says:


    Thanks for the answers. One more follow up just for my own information.

    How does password entry for decrypting home directories work for resume from suspend when the system was suspended. I’m trying to imagine how that will work when there was multiple users logged in to a desktop via fast user switching before the suspend..and my pea-sized brain is failing to come up with something plausible based on my existing understanding on ecryptfs tools.



  8. Dustin Kirkland Says:


    Your $HOME is only unmounted when you actually logout (where logout is defined as going through the PAM session close module).

    Thus, neither suspending nor fast-user-switching has an effect on encrypted home.

    While the home directory is mounted, you are relying on normal DAC permissions to protect your data. eCryptfs (and any other software encryption solutions) provide cryptographic protection of your data at rest.


  9. Dougie Richardson Says:

    Hi Dustin mate – thanks for working on this, it’s so important in the environment I’m working in.

    I think that we’re going to have to draw more attention in Ubiquity to its availability though – you mention the radio buttons and that was the first clue I had it was there!

  10. mish Says:

    So does the encrypted swap work with hibernate now? I remember you saying that was your aim, but I have never seen an announcement saying that it is the case.

    Also, how is encrypted swap done? Random key? Key stored in a file on a non encrypted bit? User password (with obvious problems if different users are using the system …)

  11. Dustin Kirkland Says:


    Our encrypted swap implementation uses a random key generated at each boot. We don’t yet have hibernation working yet with encrypted swap.


  12. Fakeer Says:

    Apologisies for going off topic. But have you stopped trekking/travelling? Your post “Hackers trek through Scotland” or sth like that brought me here and I am still waiting for sth more.. šŸ™‚

  13. Dustin Kirkland Says:


    Heh, yeah, off topic šŸ™‚ Actually, I went back to Scotland last month, and had a blast again. I still need to write up that trip report. Thanks so much for the interest, and the reminder!


  14. Adam Says:

    I usually set up my Ubuntu with a separate partition for the home directory. When I reinstall I just wipe the root partition and put a new Ubuntu installation on it, keeping my existing /home partition but recreating the users.

    Does encrypted home directories work with this way of doing it? Is there a way to connect already encrypted home directories?

  15. Dustin Kirkland Says:


    As of 9.10, yes, that will work fine. All of the encrypted data is actually stored in /home/.ecryptfs/$USER/.Private, and all of the ecryptfs configuration data is stored in /home/.ecryptfs/$USER/.ecryptfs.

    This was *not* the case in 9.04. There was some configuration data stored in in /var/lib/ecryptfs/$USER. I can’t tell you how many people did not record their generated password as instructed and inadvertently wiped their /var partition with a reinstall.

    As I said, we have rectified this situation in 9.10. And I have posted instructions on how 9.04 users could/should migrate to this setup:
    * http://blog.dustinkirkland.com/2009/08/moving-your-encrypted-home-meta-data.html


  16. Jef Spaleta Says:


    Can you look into forcing the locked screensaver ui to engage on resume from suspend for encrypted home directories?

    There is a potential weakness here in the model for laptop owners. Theft of a suspended system may encrypted data open for copying..if there is no password dialog required on resume from suspend.

    Or barring a technical solution which forces a password UI to engage on resume can you make sure that is covered in the release notes. Worst case is someone assumes their data is safe even when the laptop is in suspend when its not.


  17. Dustin Kirkland Says:


    I agree with you, that requiring a password on resume-from-suspend is security critical.

    But this is the default behavior in Ubuntu (except where login-automatically is selected, and as discussed above, this is incompatible with encrypted-home).

    Thanks for the concern and the keen eye for security.


  18. btberch Says:

    Thanks for your work.

    While I have used Linux for 10 + years, I am new to encryption. As I understand it, the decryption process takes place with the entering of your login name/password after installing fresh with home folder encryption. That being said, my question is does changing ones password cause any problems with decryption or should the password not be changed?

    Maybe stupid question, but like to know ahead of time.

  19. Dustin Kirkland Says:


    Not a dumb question at all. Yes, we absolutely have taken care of this situation. Basically, your login password is only used to decrypt/encrypt a much longer, random passphrase which is used for the actual filesystem mounting.

    So when you change your system password, we merely need to unwrap your mount passphrase file with your old password, and re-wrap it with your new password.

    If you’re interested in more of the details, please read:
    * http://blog.dustinkirkland.com/2009/02/how-encrypted-home-ecryptfs-works.html


  20. Adam Says:

    Okay, so as long as you keep your generated password (passphrase?) and use it with your new account you should be okay?

    Is that set up automatically during install or do you have to associate your new user account with the old data in some way?

  21. Dustin Kirkland Says:


    Right. As long as you have your generated passphrase, you can recreate everything else.

    It should be setup automatically in the install, however, this is something I need to test.


  22. mish Says:

    So does changing your password in the normal ways ( $ passwd, “About Me” dialog) update the ecryptfs passphrase file, or is that a manual process you have to do separately.

    If it is a separate process, could you write a blog post explaining how to update the passphrase file?

  23. Dustin Kirkland Says:


    Both of those methods should work as expected.

    The only one that’s known not to work is when root forcibly changes another user’s password, since root is not prompted for that user’s old passphrase, the rewrap doesn’t work.

    In this case, the user will need to manually run ecryptfs-rewrap-passphrase, or run ecryptfs-wrap-passphrase with their recorded key.

    I don’t think a blog post is necessary. Just see the manpages.
    * http://manpages.ubuntu.com/manpages/karmic/en/man1/ecryptfs-rewrap-passphrase.1.html
    * http://manpages.ubuntu.com/manpages/karmic/en/man1/ecryptfs-wrap-passphrase.1.html


  24. Adam Says:

    Thanks! I think I feel confident enough now to enable it when Karmic comes.

  25. Adam Gonnerman Says:

    Cool. Something to look for when I upgrade next month. Thanks for the heads up.

  26. jajaja Says:

    Quote: “I believe Ubuntu now provides the most user-friendly personal data encryption solution in the industry.”
    Quote: “Your $HOME is only unmounted when you actually logout (where logout is defined as going through the PAM session close module).
    Thus, neither suspending nor fast-user-switching has an effect on encrypted home.
    While the home directory is mounted, you are relying on normal DAC permissions to protect your data. eCryptfs (and any other software encryption solutions) provide cryptographic protection of your data at rest.”

    It doesn’t make much sense for laptop-owners, if data is not encrypted after suspend/hibernate (which I use mostly instead of shutting down / logging off for fast usage of my computer) .
    Fedora allows full disk encryption with their installer using LVM – even after suspend/hibernate data is encrypted and one needs a password to decrypt. This scenario is also compatible with auto-login.
    What is the advantage of ecryptFS over the encryption with dm-crypt / LVM?

  27. Dustin Kirkland Says:


    Ubuntu, like Fedora, also supports dmcrypt + LVM in the installer.

    And while I think dmcrypt + LVM is an excellent solution in some scenarios, I think eCryptfs + encrypted home has a couple of significant advantages over dmcrypt + LVM…

    dmcrypt + LVM is not acceptable in many server environments, or anywhere a machine is expected boot unattended. Systems such as this in a data center will just hang, shortly after the bootloader, waiting for someone to walk by and type in a password. In the eCryptfs + Encrypted Home world, we require a password at login time, rather than to boot the system.

    Secondly, dmcrypt + LVM encrypts *everything*, including /usr, /lib, and so on. In some cases, perhaps this is what you want. But in many cases, this is encryption overkill. How much secret data do you really have in /usr or /lib? I’ll admit that super secure, really paranoid people might prefer encrypting everything (particularly /var), but I don’t believe that’s the case for most laptop users, and you pay a performance penalty on every file read or written.

    Third, in multi-user systems, each user’s $HOME is encrypted with different keys. This provides some subtle separation of the encrypted data. In the dmcrypt + LVM case, all users on the multi-user system would need to share the same key to boot the encrypted system.

    Finally, from an incremental backup standpoint, eCryptfs provides a tremendous advantage. Each file is independently encrypted. Thus a user can rsync their $HOME/.Private directory to remote storage, only sending the files that have changed. This is really, really impractical with LVM. You can’t really rsync /dev/sda3…

    In terms of suspend/hibernate, as long as you require a passphrase to log back into your system on resume, your data is secure, even though mounted. How else is someone going to access your data? I’m interested to know…


  28. jajaja Says:

    If I from a USB-Stick or a Boot-CD or just take out the harddrive of the hibernated machine and plug it in a different machine, isn’t my data in $HOME readable if it’s mounted?
    Or maybe I don’t get the concept?

  29. Dustin Kirkland Says:


    First of all, at least with Ubuntu 9.10, your swap is going to be encrypted, which means that hibernation is not going to work.

    So, yes, you could move that hard drive elsewhere. But if the swap is encrypted, and you don’t have the swap encryption key (in Ubuntu, it’s randomly generated at boot), then the data is inaccessible.

    In the suspend case, you won’t get anything out of moving the hard drive, as the data wasn’t moved to disk (it stayed resident in RAM, which requires power to preserve stat).`


  30. btberch Says:

    Thanks for the reply. I did a fresh install from alpha 3 to alpha 5 to try out the install of the encrypted home. Nice feature. Booting up to the login screen seemed to be a little longer, but I wouldn’t think that would be the encrypted home file. As for logging in, it only takes 10 to 15 seconds longer. I been using karmic on a toshiba nb205 netbook and would expect things to go slower on it.

    Thanks again

  31. jajaja Says:

    Quote: “First of all, at least with Ubuntu 9.10, your swap is going to be encrypted, which means that hibernation is not going to work.”

    I don’t think that is a step in the right direction (even though hibernation is quite unreliable with Ubuntu and fails every 2nd or 3rd time with a “not enough swap”).
    Having to shutdown and reboot every time you’re disconnected from power for a while is a big hassle.

  32. Dustin Kirkland Says:


    I respect your opinion, though I disagree.

    I find suspend-to-ram adequate for most of my needs, which works very, very well on my Intel-based Thinkpad

    And the boot speed has improved so much in Karmic that I now just poweroff instead of hibernating.


  33. jajaja Says:

    On my Dell suspend-to-ram never worked.
    With an older battery, I wouldn’t rely on suspend-to-ram if you’re e.g. on a longer plane trip.
    Only hibernation guarantees zero power consumption…

  34. Dustin Kirkland Says:

    And poweroff.

  35. jajaja Says:

    … which requires rebooting, opening your documents again, scrolling to the point in your document where you were before, etc. pp. (session saver is NOT an adequate replacement for waking up from hibernation).
    And in other OSes a wake-up from hibernation takes 5 -10 seconds (depending on your RAM)…

  36. Dustin Kirkland Says:


    I invite you, then, to skip over the encrypted-home option. It’s not required, and it’s not even default. Use dmcrypt+LVM to encrypt your system, if you so wish.

    Many people will, and do find Ubuntu’s Encrypted Home useful.

    I have no interest in continuing to respond to your trolling.


  37. jajaja Says:

    will do. sorry that you feel offended.

  38. Surfin Says:

    Dustin, I clicked on the link to your changelog and it says the page cannot be found.

  39. Dustin Kirkland Says:


    Thanks. Link fixed.


  40. Dill Says:

    If I encrpyt my home folder does that mean all the files are still encrypted when they are uploaded if I’m using Ubuntu One?

  41. Dustin Kirkland Says:


    Only if you upload the encrypted version of the file.

    Personally, that’s what I do. I sync my $HOME/.Private directory to Ubuntu One, such that my privacy is preserved there. There are a few drawbacks, though. If you use the web interface to browse your files in Ubuntu One, you only see encrypted filenames and data. That’s okay by me, though. I don’t use the web interface that much.


  42. Dill Says:

    I don’t have ubuntu one yet, so sorry if it’s a dumb question: Isn’t the Ubuntu one folder within the home folder? If so, would the default behavior be that the data remains encrypted when uploaded by ubuntu one if I have my whole home folder set to be encrypted?

  43. Igor Gomes Says:

    Justin, how about to further discuss about a perfect partitioning scheme in Karmic? Maybe covering topics like LVM, encryption, separating personal data etc.

    It will be great to have it as a guide to the next upcoming release.


    Igor Gomes

  44. Felix Says:

    Hi Kirk,

    I’m using Karmic with encrypted home directory. So I wasn’t able to see my desktop after I had changed my login password (Through Users and Groups).

    I tried getting it to work with the the “ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase” command. This also didn’t work. I tried many things, but to make a long story short…

    Looks like I messed up my unwrapped Mount Passphrase, since when I unwrap it now it shows my current password instead of the initial phrase (that I also backed up after installation)

    Now my question: Is it possible change the unwrapped mount phrase back to what it was using my backup? What command would I use for that?

  45. Dustin Kirkland Says:

    You can fix your setup with ecryptfs-rewrap-passphrase.

    You should really use either passwd from the command line, or System->Preferences->About_Me to change your password.

    I think Kees *just* fixed the bug you mentioned.


  46. Felix Says:

    Hi Dustin,

    First of all sorry for mixin your name up. Well I tried ecryptfs-rewrap-passphrase and the command was successfull.

    But I still cannot mount my home dir. When I do ecryptfs-unwrap-passphrase it still shows “my login password” as my passphrase instead of the “987324072749032075” which I recorded as my mount passphrase after installation. (Or am I getting something wrong here?)

    I guess everything should be fine if I get my recorded passphrase back in there.

    How can I achieve that?



  47. Dustin Kirkland Says:


    Right, so if you’ve recorded your long, random passphrase, you should be able to just run ‘ecryptfs-wrap-passphrase’ and store that in $HOME/.ecryptfs/wrapped-passphrase. That should get you going šŸ˜‰


  48. Felix Says:

    Thanks Dustin that did the trick.

  49. Julian Says:

    After reading all the answers and questions from the people here has answered *all* my concerns.

    You should really put them in a FAQ, because your detailed explanations are gold. Sorry to be somehow off topic. But I wanted to thank you Dustin for your contribution.

  50. Mikko Ohtamaa Says:

    There is very nasty installer user experience bug related to encrypted home – indicator hangs for several dozens of minutes:


    Also the encrypted home has serious performance issues:


    I opened a “tuning thread” related to tuning the performance at ubuntuforums.org:


  51. Dustin Kirkland Says:

    The installer is clearing the swap space, which is absolutely necessary to secure your setup.


  52. Julian Says:


    I find your complain very misleading to people reading this blog. You should mention what has been tested there! If you read the hardware tested, it was a Dell netbook with an Intel Atom N270 CPU.

    What do you expect? It’s an Atom CPU for God’s sake! Test on a Core 2 duo to have a more representative benchmark.

    I’d like to see how this Netbook performs with Windows 7 Ultimate and bitlocker, or full disk encryption. Probably not that well either. The full-disk encryption test made a year earlier by the same people was on AMD Athlon 64 X2 4200+ AM2. So we are comparing apples and oranges.

    I have tested the latest Karmic Beta with home encryption on my Core2 duo and I’m very happy with the performance. I have also tried with full-disk encryption and with encrypted home I perceive a faster booting.

    So please instead of saying “Also the encrypted home has serious performance issues”

    better say “encrypted home is not really suitable for netbooks or low-end CPUs”.

    Dustin, what about this? I have an idea:
    Before offering the menu with installation options, run a quick CPU benchmark. If the test detects a slow CPU and the user selects home encryption, issue a warning that it might be too slow. If the CPU test is really discouraging, disable the option altogether or suggest Private folder instead.

    After all, most people use netbooks for browsing, where encryption should have a minimal effect. Who would run an SQL server on a netbook? And if you are afraid of performance loss, just have the Private directory separated from your home.

    I really don’t see a problem with the current implementation. All the contrary, we have one more option to the set

    – No encryption
    – Home encryption
    – Private directory
    – Full disk encryption

    By the way, is the Private directory gone or offered by the alternate install CD? I’d keep it as an option for advanced users.

    The only thing missing is a container-based home encryption with dynamic size, just like MacOS X. A fixed size container based, like Opensuse, is in my opinion not that good.

    At the moment, I think the major downside to eCryptFS is its lack of Windows drivers. You can’t access your files from Windows. But neither can you with Luks+LVM šŸ˜¦

  53. jajaja Says:

    Quote: At the moment, I think the major downside to eCryptFS is its lack of Windows drivers. You can’t access your files from Windows. But neither can you with Luks+LVM šŸ˜¦

    I think that’s not correct:
    http://www.freeotfe.org supposedly supports LUKS and LVM, see http://www.freeotfe.org/downloads/FreeOTFE_PC5_10_PDA5_10.pdf on Page 99.

  54. Alexander Says:

    how do you turn off home drive encryption??

  55. Julian Says:


    I wish you were right. But all the documentation says is that it should work, as long as other applications stack on top of it. I couldn’t find an Ext2/3 file manager that supports LVM and recognizes volumes decrypted by freeotfe. I couldn’t find references to anyone who succeeded doing this either. This was about 4 months ago.

  56. thomas.e Says:

    Just found this great blog. Thanks for it.

    I still have some questions. I’m using Linux for some years now (mainly Arch Linux) but never dived into the world of encryption.

    On my Netbook I recently installed Ubuntu 9.10. by just wiping my / and leaving /home as it is.

    I was interested in the encryption thing so I marked the appropriate option during installation.

    First, I didn’t know about encrypted swap and hibernation so I changed my fstab back to a “normal” swap. I only commented the encrpyption line so can I undo this by just uncomment it?

    I’m also not sure if my /home is encrypted although I marked this option. Booting from a Live USBDrive allows me to read my home using nautilus as root.

    Did I miss a step or is encrpytion only possible with fresh /home?

    Thanks in advance!

  57. Dustin Kirkland Says:


    If you can read your home directory contents from a LiveCD without entering a password, then yes, you missed a step. Your home directory is not encrypted.

    You should be able to just uncomment that line again in your fstab (and remove any other non-encrypted swaps you might have) to re-enable encrypted swap.

    As for migrating your non-encrypted $HOME to an encrypted $HOME, you certainly can do this by following the steps at:
    * http://blog.dustinkirkland.com/2009/06/migrating-to-encrypted-home-directory.html


  58. barghest Says:

    Hi Dustin,

    thanks for the swift reply. Ok, so an already existent home isn’t encrypted automatically.

    Thanks for the link – I’ll try (fortunately there’s already a hint for using rsync with an encrypted home in the comments)


  59. tatoute Says:


    You said

    In terms of suspend/hibernate, as long as you require a passphrase to log back into your system on resume, your data is secure, even though mounted. How else is someone going to access your data? I’m interested to know…

    Suppose your system is hibernating. That mean the full state of the machine is sleeping on disk (full copy of the ram). Including the current crypt/decrypt key.

    I do not want to explain here use how to use this fact but it is clear that crypto-security is broken.

    For suspend case it may be more complex, but feasible as well. One best idee may be to find a mean to go from suspend to hibernate.

    Another method would be (for example if disk is a sata disk) to access to the sata socket (the pc still suspended), plug out the disk, plug it to another PC (sata is hot pluggable) and insert some backdoor. Then plug it back.

  60. Hand Says:

    I’m considering syncing the private files to Ubuntu One, as you are doing. Do I have to log out to get the ecrypt fs to sync my data to the ecrypted store? Can I do that manually? (I normally leave this machine logged in for weeks at a time). Thanks, cheers, W

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: