Last update: March 17, 2019. This website uses cookies. By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. More information


Full Disk Encryption and Encrypted Images

About this Full Disk Encryption and Encrypted Images Page
Support Status stable
Difficulty easy
Maintainer HulaHoop
Support Support

Full Disk Encryption on the Host[edit]

Protection Against Powerful Adversaries[edit]

To protect against theft or robbery of personal information or data, users should apply FDE (Full Disk Encryption) on the host, and power off their computer when exposed to higher-risk situations like traveling. Laptop users should temporarily remove the laptop battery after powering off. This ensures that the RAM chips are completely powered down and that any encryption key/s in memory are erased. Hibernation is also a safe alternative, as the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), provided the user did not change anything.

Users should follow the standard advice for picking strong and unique passphrases, so they cannot be feasibly brute-forced. Computers should never be left unattended in untrusted venues.

Debian Hosts[edit]

Configuring FDE during system install is straightforward. The default cipher is AES-256 in XTS mode.

Removable Media[edit]

New Removable Media[edit]

Gnome Disks Utility creates LUKS partitions with AES-128 by default which is insufficient in event of quantum computers materializing. This has been successfully reported and fixed upstream as of February 2019, [2] [3] but until it lands in Debian, an appropriately secure container must be manually created. Afterwards, unlock the device and format the internal filesystem as EXT4 in Gnome Disks.

First enumerate the device. They will usually be called 'sdb1', as sdaX is reserved for the system on default installs. To avoid confusion, only connect one removable device at a time:

# ls /dev/

Create a LUKS container and change the device name as needed, then follow the prompts:

# cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --use-random luksFormat <device>

Legacy Device Encryption Upgrade[edit]

It is safer to re-encrypt the device with a stronger key rather than performing a quick format that will otherwise leave the old/weaker header intact.

First enumerate the device. They will usually be called 'sdb1', as sdaX is reserved for the system on default installs. To avoid confusion, only connect one removable device at a time:

# ls /dev/

To view the LUKS header data in order to make necessary adjustments, run:

# cryptsetup luksDump --debug <device>

LUKS header data legend:

  • 'MK' means 'Master Key'. [4]
  • AES in XTS mode uses a key size double its bit size (512 in this case) since in XTS the key is split in 2, resulting in AES with 256-bit keys. [5]
  • 'Payload offset' is 4096 for 256-bit keys and 2048 for 128-bit keys. [6]

Re-encrypt the device with stronger keys. [7] Fortunately, header resizing is usually unnecessary (otherwise it will abort the process):

# cryptsetup-reencrypt <device> -c aes-xts-plain64 -s 512 --use-directio

Abruptly disconnecting power can cause data loss. To safely pause the process (in case of system sleep/shutdown), cryptsetup can be suspended (e.g. by Ctrl+c) and it will automatically restart from where it left off if temporary header files are present in the home directory. [8]

If unauthorized access is strongly suspected or confirmed, the hardware should not be trusted or used after it is back in the user's possession. This scenario is only relevant to a smaller subset of users who are already targeted for physical surveillance. A sufficiently skilled adversary can infect it with spyware or sabotage it in a number of ways that are virtually undetectable. For example, malicious firmware could be installed to record all activities, or the machine rendered inoperable by bricking the hardware. In that eventuality, none of the measures outlined will help.

Additional Measures[edit]

LUKS Suspend Scripts[edit]

On Linux hosts, there is one interesting solution for the risks posed by a computer in a suspended state; luks-suspend scripts. [9] This approach has some limitations because it is not yet packaged for Debian, and it has only been tested in the Ubuntu and Arch distributions. As of 2018, luks-suspend and keyslot nuking (mentioned below) is being merged upstream. [10]

Magic Key Feature[edit]

In an emergency, Non-Qubes-Whonix users can power-off the computer immediately with the Magic SysRq key feature. This is invoked by pressing the key combination: Alt + PrintScreen + o (lower-case letter). On bare-metal linux systems, the FDE passphrase is prompted after rebooting.[11] [12] [13] The magic key feature does not work on Qubes hosts because the Xen hypervisor does not recognize these commands. [14]


USBKill is an anti-forensics script written in the aftermath of the SilkRoad trial. Its purpose is to trigger protection events that prevent adversaries from siphoning files, installing malware, or running a mouse jiggler. The script creates a white-list of allowable USB devices. If anything else is plugged into the machine, the RAM is erased and the computer is immediately shutdown.

USBKill can also be configured to exclude all devices from being attached. In another high-security configuration, a white-listed flash drive serves as a key, and must be in the USB port at all times. If the flash drive is forcibly removed, the program will initiate the desired routines. [15] [16]

Protection Against Lesser Adversaries[edit]

The reader is reminded that advanced attackers have virtually limitless possibilities to infect a computer under their physical control, such as flashing low-level firmware or adding physical implants.

It may be possible to get plausible deniability on Linux hosts using methods other than thosed listed below, but the topic is a rabbit hole (see footnotes in this section). [17] Plausible deniability and FDE are also useless if the user is subject to physical abuse by a captor.

Advice for Solid-state Drives and USB Storage[edit]

Unlike hard-disk drives (HDDs), overwriting data on SSDs is no longer effective in wiping the disk. [18] [19] For instance, it is insecure to rely upon a fast erase mechanism by overwriting the header and key-slot area. [20]

The most dire potential consequence is that old passwords are not erased, and for a significant period. Consider the following concrete example: a user changes their computer password because they noticed it was exposed to shoulder-surfing or CCTV. On a SSD, the old password is still retrievable and can be used to decrypt the master key and all data. The reason is that secure overwriting is only guaranteed with magnetic disks.

Wear-leveling mechanisms like TRIM also leak information about the filesystem that can aid forensics. [21] [22] [23] [24] [25] It is strongly recommended to keep TRIM disabled (the default) during Linux LUKS-encrypted installations.

Gnome Disks Utility[edit]

Gnome Disks utility provides a convenient way to manipulate LUKS container passphrases (including the host's) and the overlying filesystems. However, it should not be relied upon for encryption because it uses AES-128 as a hardcoded default [26] [27] (as of Debian Stretch), which does not provide adequate post-quantum security. For encrypting removable media refer to this guide.

To install it, run:

sudo apt-get install gnome-disk-utility

Nuke Patch for cryptsetup[edit]

The Kali penetration testing distro team has written a nuke patch for cryptsetup, which adds the option to nuke all keyslots after a certain passphrase is entered. [28]

Supplying the dead-man switch as the "real passphrase" to the interceptors of the machine is unlikely to be an effective strategy. It is standard forensics procedure to create multiple images of the drive beforehand.

Separate /boot Partition[edit]

When FDE is used on the host, it is inadvisable to keep any unencrypted files on that same physical media. High-risk users are recommended to move the /boot partition to a separate USB media. The bootloader (Grub) should then also be installed on the separate USB. To read more on this subject, see Pwning Past Whole Disk Encryption.

TRESOR Kernel Patch[edit]

Another useful protection is the TRESOR kernel patch, which keeps the disk encryption key outside of RAM by storing it inside the CPU. TRESOR does have several limitations. It is only available for the x86 architecture, and it complicates software debugging by disabling DR registers for security reasons. [29] Moreover, a specialized attacker who can reverse engineer hardware designs is also capable of extracting secrets held in processor caches or specialized chips like TPMs.

Encrypted Guest Images[edit]

The greatest security benefit comes from applying full disk encryption on the host because that is the only place where it is most effective. Nevertheless, for the interested reader this section makes recommendations to deal with the following threat model:

  • The host is running when an adversary gets access to it, or the host is unencrypted.
  • The VM is powered down (otherwise the adversary would already have access to it).

The following security considerations are based on modified quotes by Iszi from the answer posted on, which was a user contribution to stackexchange, licensed under cc by-sa 3.0 with attribution required.

Full Disk Encryption within the Virtual Machine[edit]

When using FDE within the VM, never save (suspend/pause) the VM machine state, but instead shut it down completely. If this advice is ignored, the saved machine state could be stored outside of the encrypted image. This includes a RAM dump, which contains the encryption key required to decrypt the image. Upon resuming the VM, that stored file is not necessarily securely deleted, since it is virtualizer-specific. [30]

While the VM is running, users should not use the host system's sleep, suspend, or hibernate functions. Similar to the first scenario, these actions leave a RAM dump on disk, but this time it belongs to the host. This also contains sensitive data, such as encryption keys.

Virtual Machine Files in an Encrypted Container[edit]

VM files can also be stored in an encrypted container, such as a LUKS container. Newer and native support for LUKS encryption of disk images is available as of libvirt 2.10 [31] The same precautions should be taken as outlined in the previous section, as the risks equally apply.

FDE within the VM, LUKS encrypted containers for VM images, and FDE on the host can all be used independently, or in conjunction. However, increasing the layers of encryption may begin to significantly degrade performance. End modified quote by Iszi.

Other Security Considerations[edit]

Encryption is an area with many pitfalls. The user should also consider the following:

  • KVM: It is not expected that KVM guests could access data from other process' memory pages via memory ballooning, since KVM guests are Linux processes and subject to Linux memory allocation rules. [32]
  • Memory Dumps: These are caused by BSOD or kernel crashes, and can leave unintended traces on the host.
  • Powered-down VMs: After a VM has shutdown, the RAM that previously contained the VM's encryption key might not have been wiped yet. Memory pages belonging to a terminated process do not have their contents wiped (zeroed) until they are about to be used by another process. [33] [34] [35] [36]
  • Swap: An encrypted swap provides no protection so long as the host is powered up, because the key is still in RAM.
    • Disabling Swap: This action requires a special, secure wiping of the existing swap. It is safer to have never used swap before.
  • Xen: Memory ballooning in Xen creates privacy concerns because when it is enabled the memory contents of other VMs are exposed. [37]

The host of security considerations suggest that an unrealistic set of operational rules are required to defend the integrity of a purely encrypted guest image, without host FDE.

Open Security Research Questions[edit]

The following questions and configurations require further research:

  • With swap and crash dumps disabled, it is unknown whether the virtualizer writes parts of the VM's RAM contents to the disk. TODO: Specifically ask virtualizer vendors about this possibility.
  • Potential setup configurations:
    • Theoretically, a fully encrypted operating system (currently: Debian) could be installed inside a VM and Whonix could be built using --target root inside another VM. This is analogous to the physical isolation model, but secure VM settings would be missing (similar to Manually Create Whonix VM Settings).
    • An encryption feature could be added to grml-debootstrap and/or the Whonix build script. There was an attempt to do that, but this effort has stalled.
    • cryptsetup-reencrypt could be used, allowing for the shipping of encrypted Whonix images. The master key and the password (potentially blank) would be known to the public at first. Later, users would use cryptsetup-reencrypt to fix the master key and password, that is, to make the encryption effective.

For further information about encrypted images, see How Useful is In-Guest Encryption? Users interested in running Whonix as a live OS, should read this entry. [38]


  1. Until in-RAM execution of disposableVMs is implemented in Qubes-Whonix, this threat is not easily mitigated.
  15. For example, this can be done quickly if the flash drive is attached to the user's wrist via a lanyard.
  19. cryptsetup FAQ - Section: 5.19 What about SSDs, Flash and Hybrid Drives?
  25. As tested by Whonix developer HulaHoop.
  28. In the case of VirtualBox, the file could end up in the folder ~/.virtualbox. A definitive answer requires further research.

    Memory ballooning is a memory management feature used in most virtualization platforms which allows a host system to artificially enlarge its pool of memory by taking advantage or reclaiming unused memory previously allocated to various virtual machines.


    Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused.

  34. The threat is similar to cold boot attacks, but in this case it might even be a "warm" attack, because under this threat model, the machine and RAM is still powered. PAX_MEMORY_SANITIZE and its KSPP successor may mitigate this, but at the cost of a non-trivial performance hit.

    Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the KVM documentation. It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.

  36. Live OS systems are designed to not leave traces of user activity on disk.


Whonix Full Disk Encryption and Encrypted Images wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix Full Disk Encryption and Encrypted Images wiki page Copyright (C) 2012 - 2018 ENCRYPTED SUPPORT LP <>

This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.
This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.

No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.

Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.

Random News:

Bored? Want to chat with other Whonix users? Join us in IRC chat (Webchat).

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix is a trademark. Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix itself. (Why?)

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix is provided by ENCRYPTED SUPPORT LP. See Imprint.