On my Debian-Testing-System, I want to completely conceal the home folders. That means, I not only want the data to be encrypted, but I also want to preclude determining any (or most) information from the encrypted data.

For instance, also file names should be encrypted. But not being an expert for data protection, maybe also other file/folder attributes need to be encrypted to grant privacy.

I considered ecryptfs to achieve this (Package ecryptfs-utils)

However, is this the right choice for my needs?

I also would appreciate links to step-by-step instructions on the implementation of encrypted home-folders in Debian very much!

[edit] I do a fresh install, therefore it's not necessary to migrate a previously unencrypted home folder.

  • What do you mean by “conceal completely”? Permissions protect from other logged-in users; encryption protects from people who steal the disk. Encryption hides the data, by definition, but it reveals a bit of information: with ecryptfs, IIRC, the directory structure (but not the file names) and the size, times, permissions and other metadata of each file are exposed. Is that a problem? Dec 27, 2012 at 21:31
  • it depends: Indeed I want to protect the data from people who get their hands on the disk. It may be a problem if the exact file size is exposed, as this may be a very good indicator for what's the content of the file (for example if you have the file sizes of a Rolling Stones discography, you may very well identify the different songs and the fact that it is a Rolling Stones discography).
    – Marcel
    Jan 2, 2013 at 15:20

2 Answers 2


Ecryptfs stores each encrypted file in one file (the lower file, in ecryptfs terminology). The directory structure of the lower files mirrors that of the payload files, although the file names are encrypted. The metadata (modification times, in particular) of the lower files also reveals that of the payload files. The size of the lower file is slightly larger than the size of the payload (with a fixed overhead for Ecryptfs's metadata)¹.

If you're storing your own work, where the attacker would already know roughly what kinds of data you have (“I already know this is a source code tree, and I know these are spreadsheets, what I want to know is !”), none of that is a problem. But if you're storing directory trees that may be identified by their layout (directory structure, approximate sizes, dates), then Ecryptfs is not the right tool for you.

Use encryption at the block device level. Linux provides this with dm-crypt. You can encrypt either the whole disk (except for a small area for the bootloader), or encrypt /home or some other partition. If you don't encrypt the whole disk, keep in mind that confidential information might end up in other places, especially the swap space (if you have any encrypted data anywhere, you should encrypt your swap). Note that if you go for whole-disk encryption, your computer will not be able to boot unattended, you will have to type your passphrase at the keyboard.

Since the whole block device is encrypted, the location of file content and metadata cannot be detected by an attacker who steals the disk. Apart from a header at the beginning of the encrypted area, the content is indistinguishable from random noise. An attacker could derive some information from seeing multiple snapshots of the encrypted data and studying how various sectors evolve over time, but even with this it would be hard to find out anything interesting, and this doesn't apply if you stop modifying the data after the attacker has seen the ciphertext (as in the case of a disk theft).

Many distributions offer the possibility to create a dmcrypt volume or encrypt the whole disk at install time. You may have to select the “advanced” or “server” installation image as opposed to the “desktop” or “basic” image.

The tool to manipulate dm-crypt volumes is cryptsetup. To create a dmcrypt volume, create a partition /dev/sdz9, say, then run cryptsetup luksFormat /dev/sdz9. You'll need to add the volume to /etc/crypttab; use cryptsetup luksOpen to activate the volume on the spot, or cryptmount -a after you've set up /etc/crypttab. Dm-crypt is only a cipher layer, so you'll need to make a filesystem on the encrypted volume.

Install Backtrack 5 r2 into running LUKS setup installed with ubuntu has a tutorial on setting up dm-crypt entirely manually.

¹ Experimentally, with default settings, the lower file size is the payload file size, rounded up to a multiple of 4kB, plus an 8kB overhead.

  • 1
    I second your recommendation to encrypt the entire disk (minus /boot). And in OP's case, its very easy to set up in the Debian installer. I believe "encrypt entire disk" is one of the options, even in the default ask-few-questions mode.
    – derobert
    Jan 2, 2013 at 18:50
  • I see. So basically I could choose between encrypting whole partitions (which is a bit unflexible in terms of multi-user systems or at least when it comes to growing or shrinking '/home'-folders) and encrypting on a file base (which is less secure when somebody tries to find certain metadata-patterns).
    – Marcel
    Jan 2, 2013 at 23:47
  • 1
    @Marcel Encryption is useless against them. The only way they'd have physical access to your hard disk is if it is seized by law enforcement, and law enforcement can compel you to decrypt the disk on pain of fines or jail time. You do not need any encryption whatsoever for this use case. Jan 3, 2013 at 0:29
  • 1
    I think it depends on the laws of your country if you must grant access to your data. But for a lot of countries, you are right: en.wikipedia.org/wiki/Key_disclosure_law
    – Marcel
    Jan 3, 2013 at 0:38
  • 1
    Please note, that ecryptfs does not help you at all against the lawyers of a copyright or trade secret holder! Consider all the metadata, that ecryptfs does not encrypt, namely file modification timestamps, (approximate) file sizes and directory structure. If your "Tina Turner" folder of your MP3 collection contains the exact number of files, exact file sizes and exact timestamps of the "Tina Turner" folder on your friends' computer, whose unencrypted disk was also seized, then it's obvious, what your files are. Even, if the actual content can't be decrypted!
    – Kai Petzke
    Feb 14, 2015 at 23:03

As for the tutorial, search engines seem to work, e.g. this one on howtoforge.com seems to give reasonable hints.

Generally you might want to reconsider what exactly you are trying to achieve in the end. While eCryptfs will (to some degree) guarantee confidentiality you should be aware of several things:

  • to hide the contents of home directory from other users, mere chmod go=- $HOME should suffice. If really necessary, you can use just chmod go-rw $HOME to allow them to enter the directory. AFAIU eCryptfs doesn't do much in this regard, since it relies on the underlying filesystem when it comes to access control.

  • root (and not necessarily just root) can usually do pretty much everything on most systems, so no encryption will protect the users from a malicious administrator or even a successful attacker.

If what you are trying to achieve is for theft protection, regular filesystem on encrypted partition/drive is probably a better solution - it's easier to set up, there's just one password for the whole filesystem and it's entirely transparent. In any case, you should encrypt your swap (since that is where your cleartext passwords/certificates might end up). You should also encrypt hibernation data (if you are using suspend to disk), as that's another plase where sensitive data will appear. However this might be a bit trickier.

  • thanks! In fact I want to protect the data from people getting their hands on the disk. In principle they shouldn't get a chance to identify the content as well as the type of the content (for example they shouldn't even know it is a folder with photographs they look at).
    – Marcel
    Jan 2, 2013 at 15:23
  • 1
    I've updated the answer a bit
    – peterph
    Jan 2, 2013 at 23:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .