Niebezpiecznik.pl, a popular and acclaimed infosec blog in my country, recommends full disk encryption (emphasis original) to all people (ie. "Average Joes"). They warn that in the opposite scenario device theft is likely to have catastrophic consequences.

I'm interested, however, why full disk encryption and not home folder encryption. (By home folder I also mean its Windows equivalent, that is, C:\Users\username\).

All personal data thieves might find interesting for frauds, blackmails, etc, is likely to reside in the home folder. Access to other folders can only give thieves the oh-so-important list of installed programs; so thieves will learn that the person was using Firefox or Google Chrome; Libre Office or Ms Office; maybe they will also learn the person was indulging themselves in certain video games. Other programs that are likely to be installed (Photoshop in case of graphic designers, programing IDEs in case of programmers, etc) will give them equally useless pieces of information.

Even in Windows, since Vista or 7 (I don't recall), badly written programs which would store user data in Program Files, have their write access silently redirected to Virtual Store (which resides in C:\Users\username\). Therefore I fail to see how could any personal information get leaked outside of the home folder.

The page I linked to doesn't provide rationale for full disk encryption as opposed to the home folder encryption. Therefore, may I ask if this is the general recommendation and why (not)? What threats can be mitigated by full disk encryption that home folder encryption would fail to mitigate? (Evil Maid is one of such threats, but I'm not sure if that's anything an Average Joe would have to worry about.)

3 Answers 3


I recommend Full Disk Encryption everywhere. Home folder encryption will cover a lot, but there are a few points missing:

  • Data outside of home

    Some programs will write things on /tmp, log files are going to /var/log, swap will contain sensitive data. Those directories are outside of your home, and will not be protected.

  • Protection against tampering

    I think this is the most important. If your computer breaks down for any reason, and you must send it to repairs, your home is protected, your system isn't. It will be trivial to replace binaries, or put backdoors in place.

  • Protect login password, WiFi passwords, and databases

    The same support technician can copy /etc/shadow, all data from NetworkManager, anything on /var/lib/mysql, and so on. With full disk encryption, nothing can be copied.

  • "...tampering..." This part I don't understand. With LUKS, your boot partition is not encrypted, if I'm not mistaken. Someone could replace that. That's just as bad, no?
    – MWB
    Commented Oct 18, 2021 at 6:22
  • You are correct. Boot partition cannot be encrypted. But you could just get home, boot from an USB drive and checksum /boot. It's faster than checksumming a large partition.
    – ThoriumBR
    Commented Oct 18, 2021 at 11:19

Because data can easily end up outside of your home directory. The two most common things that come to mind are:

  • Temporary files: many programs create temporary files in a system temporary directory, these can be for extracting an archive, auto-saving, and many other uses.
  • Swap file or partition: sensitive data is guaranteed to be in RAM at some point, which means it could potentially be saved to a swap file or partition. If you use hibernation then all of your RAM will be saved to the unencrypted swap file or partition (likely including the key used to decrypt your home directory!)

There are likely many other situations in which data could end up outside of your home directory without your realizing it, it's much easier to just encrypt everything than to worry about every possible scenario.

Some more pros and cons of disk vs filesystem encryption

Disk encryption pros

  • No filesystem metadata leaked*
  • Everything is encrypted, not just certain directories

Disk encryption cons

  • Generally uses XTS by default; XTS is generally "good enough" for disk encryption (that's what it was designed for), but it has some concerning properties that make people nervous, especially if an attacker has repeated access to the disk
  • Generally not authenticated**; this means if an attacker changes something it won't necessarily be detected

Filesystem encryption pros

  • Doesn't use XTS mode
  • May be authenticated, but might not be (eCryptfs doesn't seem to have any support for AEAD ciphers at the moment, other solutions might)

Filesystem encryption cons

  • May leak filenames (eCryptfs encrypts filenames by default, but there is an option to disable this)
  • Leaks a significant amount of metadata***:
    • Directory layout (directory structure, number of files in each directory)
    • File size (with the precision of a block size, generally 4KiB)
    • File metadata; can include owner, permissions, creation date, modification date, access date, and more

*If the disk isn't wiped with random data before or during the encryption setup an attacker will be able to tell how much data has been written, and may be able to guess what filesystem is used based on write patterns. SSDs in particular may have trouble with this.

**There has been talk about it but right now I don't believe either LUKS or VeraCrypt have any support for it.

***These all apply to eCryptfs, but I haven't looked at other filesystem encryption. I would expect others to be similar, though maybe differing on one or two points.

  • Maybe it should be mentioned FDE has its disadvantages over encrypting home directory as well. FDE has to use XTS while home directory encryption can use ecryptf, which has better properties. sockpuppet.org/blog/2014/04/30/you-dont-want-xts Commented May 1, 2018 at 21:54
  • 1
    @PeterHarmann Depends on the threat model. Given that the OP seems to rule out evil maid attacks where the adversary has repeated access to the encrypted disk without the owner's knowledge, I'm not sure the disadvantages of XTS really apply. I might look into ecryptfs more and update the answer tomorrow though. Commented May 1, 2018 at 22:21
  • Also /var/mail and /var/db Besides /etc/{sshd,shadow} or passwords in cronjobs and so on. And that does not even address evil-serviceperson type of attacks.
    – eckes
    Commented May 1, 2018 at 22:42
  • Some filesystem-level encryption will leak metadata like file size or, in some cases, file name. This alone has been enough for law enforcement to convict people for certain crimes without knowing the encryption key. FDE on the other hand encrypts everything, from filesystem metadata to unallocated sectors. It is unauthenticated though and you are right that that is a problem. Ideally it would either be authenticated (I think dm-crypt has an option for that now), or would use a wide-block cipher mode like EME to greatly reduce malleability (sadly EME is, or at least was, patented).
    – forest
    Commented May 2, 2018 at 0:54

It depends. In the Windows world (recent versions), the home folder should contains most of user data, including temporary files. But there are plenty of use cases where personal data will resides out of that folder:

  • mail data (/var/mail) on Linux systems
  • databases that are not private to the user. For example PostgreSQL usually uses a private account different from user's one.
  • applications using a system temporary folder (common in the Unix world)
  • applications that use a private folder for any reason (being poorly programmed being a possible one)
  • swap data

If any of these applies, then home folder encryption is not enough, and you should considere full disk encryption.

  • 1
    Swap data can be encrypted with fsutil behavior set EncryptPagingFile 1 on Windows. I think newer versions of Windows have that set by default. And with Linux, encrypting the swap file is as simple as setting up swap on an encrypted device mapper file.
    – forest
    Commented May 2, 2018 at 9:05

You must log in to answer this question.

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