I just added a drive to my system which is basically a partition mounted for extra storage. I'd like to encrypt it to protect my data in case of god knows what, and by doing that I'd need to enter the passphrase every time to unlock the partition.

I just read that I can add a keyfile so I wouldn't need to manually unlock it every time, but this is confusing. What is the point of having encryption if it's going to unlock automatically anyway?

  • 1
    How do you supply the keyfile?
    – schroeder
    Commented May 12, 2020 at 13:19
  • 20
    If an installed drive, using a keyfile adds no protection. If removable, the theft of the media is mitigated. Security is not all-or-nothing.
    – schroeder
    Commented May 12, 2020 at 13:39
  • 9
    All drives are removable. Some just take a little more work than others. And in the long term, all drives will actually be removed. It is easier to wipe a keyfile than an entire drive.
    – jjanes
    Commented May 13, 2020 at 16:56
  • 11
    "In case of god knows what," that right there is your problem: you don't have a threat model and are already looking for solutions against ... yeah, against what? Make up your mind about which kinds of data theft are a real threat to you and which you want to protect yourself against. Then choose a form of protection that suits your threat model. Encryption, in one way or another, might be the solution.
    – marstato
    Commented May 14, 2020 at 12:16
  • 4
    @jjanes: Selling a drive with all your data on it is foolish in the extreme. Wiping the keyfile does not mitigate that. It's important to realise that as time goes on encryption becomes easier to crack. Encryption is like a door - it does not prevent entry, it merely delays it. In earlier days, we used 48-bit encryption which could hopefully delay cracking for a year. Today, we can crack that in mere seconds, so we've moved on to stronger keys, but the same applies.
    – RichardP
    Commented May 28, 2020 at 0:01

4 Answers 4


If decryption only relies on the keyfile and this keyfile is readily available, there is indeed no significant security benefit in your setup.

What you can do though is store the keyfile on a removable device (e.g. a USB stick) and detach it when you are not around. That way decryption is only possible when you are present and the removable device is attached.

Storing the keyfile locally makes sense if you want to ensure that a removable device can only be decrypted on your system. You can distribute the keyfile to other systems as well if you want to use the encrypted device in different places. If you lose the removable device in transit, little harm is done, because it can only be decrypted on a system that has your keyfile.

  • 47
    …also, it's common to have the keyfile itself encrypted with a password. This has a number of advantages, but the biggest one is that it provides a form of two-factor authentication: an attacker needs to both guess your password and gain access to the keyfile in order to decrypt the data. Commented May 12, 2020 at 22:19
  • 3
    Depending on the OS and exactly how you store the keyfile, it may even be well protected if it remains on the same physical machine. For example on macOS if the key is stored in the keychain then the key itself is encrypted, and the decryption key for that is stored in the Secure Enclave - accessing this without appropriate credentials is not a trivial task.
    – jacksonj04
    Commented May 13, 2020 at 9:33
  • 1
    @IlmariKaronen thank you. I've had to vigorously defend that encryption key + password are TWO factors security.stackexchange.com/a/220416/44419 Commented May 13, 2020 at 18:14
  • 1
    The keyfile can also be printed on a piece of paper (with ASCII armor or a QR code) and placed in a secure location so that if the person who knows the passphrase is unable to provide it for whatever reason, the volume can be recovered. Commented May 13, 2020 at 21:51
  • 4
    An actual benefit of encrypting with readily available key is that it makes disposing the data much easier. Usually you'd need to erase all of the hard drive to destroy the data (e.g. before selling the drive on ebay). If you have a keyfile it is enought to destroy this file.
    – yankee
    Commented May 14, 2020 at 11:26

While Demento's answer is fine, I'd also present another user case I'm personally using: I have full disk encryption set up — using LUKS on a Linux-based box, and the scheme is implemented as follows:

  • The boot partition is encrypted and requires a password to be entered so the boot manager (GRUB) is able to mount it.
  • The partition contains the kernel image and the so-called "initramfs" which is an "early-boot userspace" used to bring up the rest of the system. This image contains the unencrypted keys used to decrypt other attached LUKS-encrypted partitions.
    The image is kept with as tight permissions as possible.

The upside of this setup is that it requires the user to only enter their passphrase once.
The obvious downside is that if the attacker somehow manages to decrypt the boot partition they automatically gain access to the rest of the disk space; if an attacker somehow manages to mount a local root exploit on a running system to gain access to the initramfs image available on the decrypted partition exported by the LUKS subsystem, it gains access to the partitions other than the boot (though, in the case of such an exploit they'd get such access right away as the partitions are already decrypted and exported).

Here, the usage of the key to encrypt data storage is to replace the need to provide a passphrase (given the key itself is kept in a reasonably secure manner).

  • If an attacker gains root access to a system with an active dm-crypt/LUKS volume they extract the master key from the kernel which allows arbitrary access to the volume in question. However, in the case of LUKS, they cannot extract the passphrase or key file content unless they “listen in” on the the volume activation since neither the kernel nor cryptsetup keep the key material around after it was used to derive the master key. Commented May 13, 2020 at 23:10
  • 2
    @DavidFoerster, in the setup I described, the keys to all the LUKS partitions except the boot one are kept as plain unencrypted files inside the initramfs file (which is a gzipped cpio archive). While the file is root:root 0600, if an attacker gets root, they would have no problem reading the archive and obtaining the keys. Of course, the attacker has to know the setup to understand where to look, but we assume they do. So the security of the non-boot partitions rests in the security of the boot partition + the security of the running system.
    – kostix
    Commented May 14, 2020 at 11:01
  • @kostix How did you install your system like this? I've been asking Canonical to implement this on Ubuntu, with some people incorrectly claiming that it cannot be done (one person even claiming that perfect security is unachievable therefore you shouldn't encrypt boot). (I wrote how to do this on *buntu, but it's tailored to Ubuntu 18.04 and isn't guaranteed to work on other versions. Thus, I'm interested in other methods, such as how you did it.) Commented May 29, 2020 at 10:14
  • @PaddyLandau, semi-manually, using this guide from the Debian's cryptsetup team. By default, the installer also adds LVM which I did not want (saw no reason to use it on a laptop which was not going to grow its logical volumes).
    – kostix
    Commented May 29, 2020 at 10:21
  • @PaddyLandau, the most crucial thing to keep an eye on there is «Until LUKS version 2 support is added to GRUB2, the device(s) holding /boot needs to be in LUKS format version 1 to be unlocked from the boot loader.», so the boot partition must be LUKS1, and the rest of them can freely be LUKS2.
    – kostix
    Commented May 29, 2020 at 10:25

Surprised that nobody mentioned TPM as an additional measure.

Doesn't protect against "god knows what" attacks, but does provide quite a bit more assurance than a keyfile, particularly against boot process attacks (if done right with sealed PCRs), giving you a bit of extra boot device security.

PIN on TPM should simplify your passphrase hassle, or a FIDO device.

Stepping on the shoulders of giants:

Having said that, suggest thinking seriously about what do you really want to protect against - stolen devices (so baddies can't use your data), forensics/decryption attempts by law enforcement (if you live in a country where things aren't stacked in your favor if you're a dissident), or you're just hiding your hentai collection from whoever. YMMV.


Security is usually achieved via a) something you have plus b) something you know, like a password secured file on a pen drive?

  • Welcome! Your answer doesn't address OP and is of poor quality. Consider reading over the question again and updating your answer. Otherwise I see no reason for your answer to remain posted.
    – phbits
    Commented Jun 2, 2020 at 15:49

You must log in to answer this question.

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