Like with any industry, the information security industry, more commonly referred to as “cybersecurity,” for all its raging debates, has rallied around a small corpus of best practices.
One of the highest on this list is full-disk encryption, which security experts regard as sacrosanct, a no-brainer that everyone should use at the barest of minimums. This is the encryption that ensures that someone who snatches your device won’t be able to know everything you’ve got saved on it.
I’m here to make the case that most of you are better off not using it. I know this might sound crazy, since I’m kind of the security guy here, but hear me out.
I am in no way about to talk you out of using encryption — without it, the digital tools that we rely on every day would be unusable. That’s why I’m not arguing against encryption, period; but specifically against full-disk encryption, and only for certain users.
What I contend is that, for most people facing the overwhelmingly most common use cases, full-disk encryption is overkill. These users enjoy no measurable gain in security compared to alternative data at rest encryption, yet they pay for it with a measurable performance hit. This isn’t just a matter of efficiency or load times, but literal increased cost to users, too.
Alternatives exist which afford normal everyday users, with normal everyday security concerns, a level of protection commensurate with what full-disk encryption offers. They are admittedly a bit off the beaten path, as most consumer tech companies have adopted full-disk encryption, but they’re out there.
There Has to Be Another Way
Today, full-disk encryption is by far the most common kind of encryption scheme for data at rest. Think of data at rest as the data you keep on some kind of storage medium (like a hard drive) for use later, not the kind of data that is moving over some communication channel like the Internet (that would be data in transit).
In general, full-disk encryption is implemented on a level of computer complexity that deals with how raw bytes, decoupled from the context of information representation, are organized on the hard drive. We will refer to this as the block device level, since the full-disk encryption is applied to the block device that is a hard drive partition (just a fancy name for a large segment of your hard drive).
This level is higher than the electrical signal level, but below the filesystem, the latter of which is the point at which your computer sees bytes as files instead of just bytes. The filesystem serves as a kind of org chart that tells your computer how to tell what bytes go together to make up files, and how to tell files and file types apart.
So what exactly is this disk encryption that isn’t full-disk encryption?
The answer is filesystem-level encryption. Under filesystem-level encryption, also called “file-based encryption,” a system encrypts certain directories (i.e. folders) and all the files and directories within them, recursively down to everything that the uppermost directory ultimately contains. Filesystem-level encryption can also encrypt an entire filesystem, automatically protecting everything that gets saved on it. For our purposes, though, we will consider the kind of file-based encryption that lets users choose which files and directories to encrypt, leaving the rest alone.
To be precise, the model I have in mind is one which encrypts only the user documents, media, and other files which on Unix systems would end up in the user’s subdirectory under the /home directory. This way, the core system files and software binaries for running programs are left alone, and only your actual personal data is guarded.
This, as the name implies, occurs at the level of the filesystem, which is one level up from where full-disk encryption is operative. This yields some important implications. To start with, all your encrypted files are already understood as being files, meaning they can be decrypted individually.
It also allows users to augment file encryption with file permission controls. Because the full disk is encrypted under full-disk encryption, a user who knows the disk decryption password has to enter it before anything else can proceed. But along with the user files, all the files the OS needs to run are also locked. A successful boot requires the whole block device to be unlocked, and once the disk is unlocked, it’s all open.
With file-level encryption, your full OS enforces the distinctions for what gets decrypted and when. Each user can define which of their files are encrypted, and with which passwords. So, with file-based encryption, one user could decrypt their files and still leave another user’s data locked up. You don’t have to decrypt an encrypted directory if you don’t want to — if you don’t intend to open any of your document or media files, you can use the computer’s programs while leaving your personal files locked up where, for instance, malware can’t infect them.
Show Me What You’ve Got
I wouldn’t go to the trouble of putting forward file-based encryption if it didn’t have some real advantages over full-disk encryption. To that end, file-based encryption’s greatest strength is that its speed leaves full-disk encryption in the dust. That’s because file-based encrypted systems read and write to the disk more efficiently.
To understand why that is, let’s get into how encrypted block devices (like a flash storage) work. Just as a refresher on terminology, “ciphertext” is the encrypted form of information, which is unreadable without the correct key, while “plaintext” is the information in its original, comprehensible form.
When you decrypt encrypted data at rest, your computer isn’t literally changing all the bits on the storage hardware from ciphertext to plaintext. That would take too long, and it would fry your drive in no time from writing to the entire drive every time you booted and shut down your device. Instead, the physical bits on your drive stay as they are, but they are read and written through a buffer that exists in memory after the correct key is applied. The buffer applies a decryption operation as the information is read, and an encryption operation as it is written, to the drive. While your data is decrypted and read, the plaintext is held in memory so it can be easily referenced until you are done with it.
Adding this many extra steps slows things way down compared to unencrypted reads and writes, by as much as a factor of ten. For full-disk encryption, every single thing you do on your computer has to be read through this decrypting buffer, because your entire block device, and its contents, is encrypted. Crucially, this includes all the binaries that run the OS itself and all the software on it.
But with our chosen configuration of file-based encryption, only your user document and media files need decryption. Most of the software you use on a daily basis isn’t among these files. There are plenty of computing tasks that wouldn’t need to decrypt anything at all. As just one example, we live in our web browsers so much that you can probably count on one hand the number of user files you’ve opened in the last 24 hours.
Obviously, your computer will have to decrypt some data some of the time, but even then, because the encryption is implemented at the filesystem level, your file-based encrypted OS can do so more efficiently than the full-disk encrypted analog would.
Ultimately, all disk access, whether to a fully encrypted or filesystem encrypted disk, requires approval from the core of the operating system, the kernel. However, because the encryption in full-disk encryption is managed at the system administrative privilege level, the kernel has to get involved for reading the block device through the decryption buffer, too.
File-based encryption doesn’t face this obstacle, because it only requires unprivileged user rights to decrypt the user’s own files. As a result, full-disk encryption has to get an additional permission from the kernel for reading or writing to the disk, compared to the same process under the file-based model.
More Efficient With Less Wear and Tear
Another major upside to filesystem encryption is that it cuts way down on wear to your drive. For every individual write operation, a system with file-based encryption simply writes less data than one with full-disk encryption.
Again, the encryption at work for full-disk encryption is on the block device level, which sees only blocks, uniformly sized units, of bytes. Not all data takes up an entire block, though. In fact, a lot of it doesn’t. So encryption at the block level actually thwarts the computer’s built-in efficiency mechanism that is only changing the parts of a file that actually changed. Without full-disk encryption, a computer can compare the updated version of a file in memory to the previous version on the drive, determine which parts are now different, and write those new different parts to the file.
Your computer can achieve a similar economy of writes with file-based encryption, too: when the plaintext version of your file in memory is updated, the file is filtered through the encryption buffer and held in memory temporarily, and then the OS compares the new encrypted version against the previous encrypted version on your drive to determine which bits actually changed, and only writes those.
Full-disk encryption is another story.
Under that model, the OS knows what parts of the file changed, but because the encryption is by block and not by file, the OS now has to translate files into blocks, encrypt the block, and write those blocks to the block device. Revisions in a file that don’t add up to a block’s worth of data can span multiple blocks, all of which must then be filtered through the encrypted buffer and written in their entirety back to the block device. Even if all the altered data is stored in one block, the whole block is rewritten, resulting in significant write overhead.
By its very nature, filesystem-level encryption yields flexibility where the full-disk alternative does not. As noted above, full-disk encryption is all or nothing. It encrypts your whole system, the core files and all user data. That means that non-sensitive data that you want to load faster (e.g. video or audio media for editing) gets hit with the read-write slowdown.
Full-disk encryption also isn’t ideal for multi-user systems, such as a shared household device. Anyone who wants to use the device has to know the full-disk decryption passphrase, or the device can’t even boot into the OS. And unlocking the device for any one user unlocks the data for all users. That also means you can’t enable features like unprivileged “guest” accounts that can use the OS with access to user files blocked.
Finally, file-based encryption is more reasonable for what most people need. I’ve said it myself that security involves inconvenience, and this is true. But when designing a set of security practices, taking on more inconvenience than necessary to mitigate the risk of attack doesn’t help. In fact, it only hurts: if a user’s security procedures are too onerous, that user will eventually cut corners.
Simply put, full-disk encryption is overkill for the use case you most likely have. The two encryption configurations we’ve been juxtaposing protect you in different ways. The main difference in the degree of security between them is that file-based encryption only protects your user document and media files. By contrast, full-disk encryption encrypts those plus core OS files.
Some Potential Downsides
As you might easily guess, there are drawbacks to not encrypting everything the way full-disk encryption does. In theory, an attacker with physical access to your device employing file-based encryption could alter the unencrypted OS data. From there, the attacker either boots your machine to run the code they just put there, or they wait until you boot your machine so that their malicious code does something to snag your data.
That sounds bad, and it is, but it also probably won’t happen to you. Really, most or none of your adversaries will even attempt it. They are either so primitive that filesystem-level encryption is enough to thwart them, or so sophisticated (i.e. powerful) that they have more efficient methods for obtaining your data.
For the overwhelming majority of users, the problem that data-at-rest encryption solves is keeping thieves who physically steal your device from getting your data. That’s why smart thieves don’t count on getting your data, and instead resort to fencing the device for money. File-based encryption and full-disk encryption both work equally well in this scenario.
Conversely, if your adversary is a government authority (e.g. law enforcement), neither file-based encryption nor full-disk encryption will save you. Depending on the jurisdiction, they can legally order you to unlock your device. Almost everywhere else, governments can issue orders to services that store your data in their cloud to just hand over what they want — and under repressive regimes, let’s just say they have more direct and painful ways of getting you to comply.
Let’s say, for the sake of argument, you are staring down a government actor, and all the aforementioned techniques haven’t worked. Full-disk encryption would only work if the government did not have a more sophisticated way of attacking your system. This is not an issue for most of the world’s powerful governments, as they are advanced enough that they can brute force or sidestep the encryption in some way.
So, there aren’t that many cases where full-disk encryption will really save you: when your enemy is a government and you can withstand physical torture, but the government isn’t capable of the really cool action movie hacking that basically every G20 nation can do.
That’s not to say that, depending on your adversary, there is nothing to be gained from making things difficult for your attacker — making your attacker’s life as hard as possible is a time-honored security strategy — but just realize that that’s all full-disk encryption can guarantee you. But, again, that’s not what almost any of you are looking at.
Practical Encryption, Impractical Implementation
Those of you who are convinced and want your read-write performance and SSD longevity back are probably wondering where you can get your hands on this sweet file-level crypto. Well, that’s where things get complicated. You see, it’s hard to set it up in practice.
The main reason for this is that major consumer OSes are already full-disk encrypted. Apple and Google have configured their mobile devices for full-disk encryption, and deny users the ability to disable it. Apple and Microsoft also enable full-disk encryption by default, but both offer ways of disabling it for the intrepid.
For Linux-based desktop OSes (my personal preference), installing your system with filesystem-level encryption used to be as easy as checking a box, but this is quickly going the way of the dodo. Ubuntu recently deprecated this installation option in their graphical installer, leaving Linux Mint as the only distribution I know of which still offers it. Even DIY distros like Arch Linux discourage you from trying to configure file-level crypto. Instead, they steer you toward block encryption, for which documentation is much more thorough.
If you are willing to go to the required lengths to turn off your full-disk encryption, there are some options available to you. One of the more robust options is VeraCrypt. Born of the desire to don the defunct TrueCrypt’s mantle, VeraCrypt is a graphical tool for creating encrypted directory structures on top of an existing filesystem. It boasts options for read-write speeds on par with unencrypted filesystems, and even super-spy features like deniable encryption, where your encrypted data will just look like normal unused space on your drive. An exploration of even basic VeraCrypt capabilities would be beyond the scope of this already lengthy piece, but perhaps it has the makings of a future article.
So why did I take all this time to tell you about something that is not the most (though certainly not the least) accessible? Fundamentally, it’s important to know what’s possible so you can make the most informed choices, to create the computing experience that is most responsive to your needs. Computers are infinitely customizable, so there is no reason a user should be denied the setup that is best for them — not knowing your options is the worst such reason.
Appreciating what’s possible is about more than living your best digital life, but about providing the support, even if it’s just usership, to the developers making it possible. If this sounds like something that could make your life better, I say to you, go forth and tinker!
Loading ...
You can keep adding points of failure until anything becomes unusable.
You can keep adding security fixes until anything becomes inaccessible to anyone.
There is no such thing as zero risk.
There is risk mitigation.
Beyond a certain point, the quest for zero risk becomes the source of new problems.