Full-Disk Encryption: BitLocker vs FileVault vs LUKS vs VeraCrypt Compared

Full-disk encryption turns everything on a drive into ciphertext and decrypts it on the fly once you unlock it. Windows ships BitLocker, macOS ships FileVault, Linux distributions ship LUKS, and VeraCrypt runs on all three. The four use the same family of cipher, so the useful comparison is how each one unlocks at boot, where its recovery key lives, and which published attacks have worked against it. Versions, defaults and documentation were checked against vendor and project pages on 10 November 2026.

Where disk encryption fits among other privacy tools is covered in privacy tools by threat model. How AES and block cipher modes work is in encryption explained and symmetric vs asymmetric encryption. This page assumes that background.

What full-disk encryption protects

Every one of these tools answers one threat: someone gets your device while its key is out of memory. Everything else depends on that condition.

Two attack classes sit at the edge of that table.

Cold boot. In 2008 Halderman, Felten and colleagues showed at USENIX Security that DRAM keeps its contents for seconds after power is cut, minutes when chilled, and recovered disk keys for BitLocker, FileVault, dm-crypt, Loop-AES and TrueCrypt from it. The defence that followed is the TCG Memory Overwrite Request (MOR) bit, which tells firmware to wipe RAM on an unclean reboot; BitLocker sets it before it loads keys into memory. In September 2018 F-Secure's Olle Segerdahl and Pasi Saarinen showed that an attacker with physical access to a sleeping laptop could rewrite that firmware setting, bringing the attack back. Apple said Macs with a T2 chip were not affected. The defence in Microsoft's own countermeasures guidance is to use a PIN, disable standby, and shut down or hibernate before the device leaves your control.

DMA. A device plugged into a Thunderbolt or similar port can read memory directly. Windows has DMA port policies such as "Disable new DMA devices when this computer is locked", and Microsoft notes that a pre-boot PIN also covers the window between unlock and the point where Windows applies those policies.

How each tool works

BitLocker

BitLocker encrypts a Windows volume, by default with XTS-AES using a 128-bit key (XTS-AES 256 is a policy option). The volume key is wrapped by one or more protectors, and the protector on the OS drive decides your security.

• TPM only (the default). The TPM releases the key at boot if the measured boot chain matches what it recorded, with no prompt. Microsoft's countermeasures page calls this "more convenient for sign-in but less secure than the other options."
• TPM with PIN. The TPM releases the key only after you type a PIN at a pre-boot screen. The TPM's anti-hammering limits guesses. The PIN is 6 to 20 digits by default; an "enhanced PIN" policy allows letters, symbols and spaces.
• TPM with startup key, or TPM with startup key and PIN: part of the key lives on a USB drive.
• Recovery password: a 48-digit number that unlocks the drive when everything else fails.

BitLocker itself is enabled on Pro, Enterprise and Education editions. Device encryption is the automatic version, available on every edition including Home on devices that meet its prerequisites. It encrypts the OS and fixed drives (never USB drives) with TPM-only protection. Windows 11 version 24H2 removed the old Modern Standby/HSTI and DMA prerequisites, so far more machines qualify.

Where the recovery key goes is the part most owners never see. After setup the drive sits in a suspended state with a clear key. That clear key is removed only once a recovery key is backed up:

• Microsoft Entra joined: to Entra ID. Domain joined: to Active Directory.
• Otherwise: when an administrator signs in with a Microsoft account, the recovery key is uploaded to that online account and the TPM protector is created.
• Local accounts only: Microsoft's documentation says the device "remains unprotected even though the data is encrypted".

The upload has consequences. Forbes reported in January 2026 that Microsoft gave the FBI the BitLocker recovery keys for three laptops under a search warrant served in early 2025, in a Guam fraud investigation. Microsoft told Forbes it receives roughly 20 requests for BitLocker keys a year and cannot comply when the key was never backed up to its cloud. If your threat model includes legal process against Microsoft, move the key: add a new recovery password protector, store it offline, and delete the old one along with the copy in your account.

FileVault

On Macs with Apple silicon or a T2 chip, the internal volume is always encrypted with AES-XTS, and all FileVault key handling happens in the Secure Enclave. With FileVault off, the key is protected only by the hardware UID, so the protection rests on the macOS login screen. Turning FileVault on wraps the key with a key derived from your login password combined with the hardware UID. Because the data is already encrypted, Apple says this takes effect immediately, with an anti-replay mechanism so the old key can no longer decrypt the volume.

There is no TPM-only mode to weaken: a FileVault Mac asks for a user password before the volume opens. Recovery options are:

• Your iCloud account, if you allowed it to unlock the disk during setup.
• A personal recovery key, a 24-character code. Apple Platform Security says it is stored in the keychain and syncs to your other devices if you use iCloud Keychain; it can be entered in recoveryOS or at the login window.
• An institutional recovery key, escrowed by an organisation's device management service on managed Macs.

Apple's support page is blunt about losing both password and recovery key: "your files and settings will be lost forever."

LUKS2 and cryptsetup

LUKS is the on-disk format for Linux disk encryption; cryptsetup creates and opens it, and the kernel's dm-crypt does the encryption. Current cryptsetup builds default to:

• Format: LUKS2.
• Cipher: aes-xts-plain64. The compiled default key size is 256 bits, and cryptsetup doubles it for XTS (which uses two internal keys), so a default volume uses a 512-bit XTS key, which is AES-256.
• Passphrase KDF: Argon2id, a memory-hard function, benchmarked to take about 2 seconds on the machine that formats the disk. LUKS1 only supports PBKDF2.
• Key slots: up to 32 in LUKS2, so a passphrase, a recovery key, a FIDO2 token and a TPM2 enrollment can each unlock the same volume.

Distribution installers set this up when you tick "encrypt disk". By default you type a passphrase in the initramfs at every boot, which is pre-boot authentication. systemd-cryptenroll adds TPM2 unlocking: it generates a random key, stores it in a new key slot, and seals it to the TPM bound to the PCR values you choose. Two details matter:

• PCR binding changed in systemd 258. Older releases bound to PCR 7 (the Secure Boot policy) by default. From 258 the default PCR mask for new enrollments is empty, because Secure Boot policy now changes about as often as firmware does. systemd recommends systemd-pcrlock policies for PCR 7, combined with signed policies for PCR 11. Leave out --tpm2-pcrs on 258 or later and nothing about the boot chain is checked: any operating system booted on that machine can ask the TPM to unseal the key.
• TPM2 with PIN. --tpm2-with-pin=yes requires a PIN in addition to the PCR check. Wrong PINs count against the TPM's dictionary-attack lockout, which is global to the chip. Since systemd 262 the PIN is also hardened with Argon2id, so a compromised TPM alone does not yield the volume key.

VeraCrypt

VeraCrypt is the open source successor to TrueCrypt, maintained by IDRIX. It does three jobs:

• Containers and volumes. A file, partition or whole drive becomes an encrypted volume you mount on demand, on Windows, macOS or Linux. This is its most common use: an encrypted USB drive readable on any of the three.
• System encryption of the Windows system partition or drive, with its own pre-boot password prompt. It is Windows-only. In UEFI mode it encrypts the partition where Windows is installed and leaves the EFI system partition readable.
• Hidden volumes and hidden operating systems for plausible deniability.

Volumes default to AES, with Serpent, Twofish, Camellia, Kuznyechik and cascades available, all in XTS mode. Header keys come from PBKDF2-HMAC (SHA-512, SHA-256, BLAKE2s-256, Whirlpool or Streebog), and since 1.26.29 non-system volumes can use Argon2id instead. System encryption stays on PBKDF2. A PIM value raises the work factor. TrueCrypt volume support was removed in 1.26.7 (October 2023); 1.25.9 can still mount and convert them. The current release is 1.26.31, published on 2 November 2026.

Quarkslab audited VeraCrypt 1.18 for OSTIF in 2016, two engineers over 32 person-days. OSTIF's summary counts 8 critical, 3 medium and 15 low or informational findings. Version 1.19 fixed most of them; some, such as an AES implementation open to cache-timing attacks and volume headers without a real MAC, were left with documented workarounds.

Hidden volumes and their limits

A hidden volume lives inside the free space of an outer VeraCrypt volume. Free space is filled with random data at creation, and the hidden volume's header sits in a region that holds random data when no hidden volume exists. Typing the outer password mounts decoy files; typing the hidden password mounts the real ones. VeraCrypt says it "should be impossible to prove" a hidden volume exists, and lists security requirements that must hold for that to stay true. Those requirements are where deniability fails in practice:

• Flash storage. SSDs and USB flash use wear-levelling, so old copies of sectors can persist. VeraCrypt says hidden volumes should not be stored on such devices.
• Repeated snapshots. An adversary who images the container twice can see which sectors changed, and changes inside the "free space" then need a plausible explanation. Cloud sync and backups create exactly those snapshots.
• Journaling host filesystems. A container file on NTFS may leave remnants elsewhere on the host; VeraCrypt suggests a partition-hosted volume or a non-journaling filesystem such as FAT32.
• The operating system. While the hidden volume is mounted, the OS and applications may write file names, recent-file lists and temporary files to unencrypted disks. VeraCrypt's answer on Windows is to mount hidden volumes only from a hidden operating system or a live system that writes to a RAM disk, and on Linux only from a live system.
• A 2026 bug. VeraCrypt warns that a security issue fixed in 1.26.29 "may affect the plausible deniability" of hidden volumes in file containers created with 1.26.6 through 1.26.28. On Windows, quick-formatting such a hidden volume wrote plaintext zero sectors at 128 MiB intervals. Its advice is to recreate the outer container and hidden volume with 1.26.29 or later and securely erase the old one.

Deniability is also a legal and social question. A file of pure random data on your laptop already invites the question of what it is, and in some jurisdictions refusing to disclose a key is an offence of its own.

Comparison table

Attacks with dates

Why TPM sniffing works. On many laptops the TPM is a separate chip connected over an LPC or SPI bus. In TPM-only mode the TPM sends the BitLocker volume master key to the CPU across that bus in the clear at every boot. Denis Andzakovic captured it in 2019 from an HP laptop's TPM 1.2, using a logic analyser, and from a Surface Pro 3's TPM 2.0, using an FPGA board costing about NZD $40. Microsoft's reply to him: "BitLocker recommends that if customers care about this level of attacks, that they use Pre-boot authentication." In February 2024 Thomas Roth (stacksmashing) published pico-tpmsniffer, a Raspberry Pi Pico board that presses onto a debug connector on some Lenovo laptops; it supports LPC TPMs only. Firmware TPMs built into the CPU have no exposed bus to tap, though faulTPM showed in 2023 that AMD's could be attacked through the chip's voltage supply instead.

Why bitpixie works. A Windows boot manager bug that dated back to 2005 failed to clear the BitLocker key from memory before a PXE soft reboot. Microsoft patched it in late 2022, but the TPM in its default configuration (PCRs 7 and 11) releases the key to any boot manager signed under the Windows Production PCA 2011 certificate, including the old vulnerable one. An attacker boots the old boot manager over the network, lets the soft reboot leave the key in RAM, then reads it from a second OS. Neodyme's write-up says removing PXE from the firmware menu does not help, because USB network adapters and recovery menus still reach it. What stops it is pre-boot authentication, or moving to a boot manager signed with the 2023 certificate so the TPM refuses to unseal for the old one (Microsoft's KB5025885 process).

What none of these broke. The cipher held in every case. The attacks went after the key while the machine was handing it over, or, in faulTPM's case, after the TPM that guards it. None of the attacks above recovers data from a powered-off drive protected by a strong passphrase without guessing that passphrase. The faulTPM authors concluded that a TPM-and-PIN setup is less secure than a reasonable passphrase with no TPM, because once the TPM is broken its anti-hammering is gone, and what BitLocker still protects depends on how complex the PIN is.

Worked example: closing the TPM-only gap

Windows: add a startup PIN to BitLocker

Start with a laptop that has device encryption or BitLocker on with the default TPM protector. Run these from an elevated prompt.

1. List the current protectors. On a default setup you will see TPM and Numerical Password.

manage-bde -protectors -get C:

2. Allow a startup PIN. In the Local Group Policy Editor (Pro and above; Home has neither the Group Policy Editor nor full BitLocker, so this procedure does not apply there), open Computer Configuration, Administrative Templates, Windows Components, BitLocker Drive Encryption, Operating System Drives. Enable Require additional authentication at startup and set Configure TPM startup PIN to Require startup PIN with TPM. Enable Allow enhanced PINs for startup if you want letters and symbols, and check that your firmware accepts them at the pre-boot screen.

3. Add the TPM and PIN protector from an elevated PowerShell. Microsoft's Add-BitLockerKeyProtector reference builds the PIN with ConvertTo-SecureString "1234" -AsPlainText, which puts the PIN on the command line and is too short for the default 6-digit minimum. Reading it with Read-Host -AsSecureString keeps it off the screen:

$Pin = Read-Host -AsSecureString -Prompt "Startup PIN (6 to 20 digits)"
Add-BitLockerKeyProtector -MountPoint "C:" -Pin $Pin -TpmAndPinProtector

The Control Panel route (BitLocker Drive Encryption, "Change how drive is unlocked at startup", then "Enter a PIN") does the same thing; the link appears once the policy in step 2 is enabled.

4. Run the -get command again. The list should show TPM And PIN and Numerical Password. If a TPM protector is still listed, delete it with manage-bde -protectors -delete C: -type tpm. Microsoft's documentation says the presence of a TPM-only protector "negates the effects of other TPM-based key protectors", so the PIN does nothing while it remains.

5. Reboot. A blue BitLocker screen asks for the PIN before Windows loads.

What the PIN buys, in numbers. Microsoft's configuration guide gives an example TPM 2.0 lockout of 32 immediate guesses and then one guess every two hours, about 4,415 guesses a year. At that rate:

The lockout parameters are set on the TPM and vary by firmware and policy, so treat these as orders of magnitude. They also assume the TPM itself holds: after a faulTPM-style extraction, what BitLocker still protects depends on how complex the PIN is, which is why Microsoft recommends a "sophisticated alphanumeric PIN" against a skilled attacker. Either way, a sniffer or bitpixie gets nothing until the PIN is typed.

Finally, follow Microsoft's countermeasures advice for a capable attacker: disable standby (S1 to S3) sleep states and shut down or hibernate before the laptop leaves your hands. Resuming from sleep does not ask for the PIN; resuming from hibernation does.

Linux: enroll a TPM2 alongside your LUKS passphrase

This is example 4 from the crypttab(5) man page. Replace /dev/sdXn with your LUKS2 partition; it asks for an existing passphrase to authorise the new slot.

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn
sudo systemd-cryptsetup attach mytest /dev/sdXn none tpm2-device=auto

The first command adds a TPM2 key slot bound to PCR 7. The second tests the unlock; on systemd older than 255 the binary is at /usr/lib/systemd/systemd-cryptsetup instead of on the PATH. For the root volume, the matching /etc/crypttab entry carries tpm2-device=auto, and depending on your distribution you may need to rebuild the initramfs. Keep your passphrase slot: a firmware update or a Secure Boot database change alters PCR 7, and the passphrase is how you get back in.

On a laptop, add --tpm2-with-pin=yes to the enrollment. Binding to PCR 7 alone ties the key to the Secure Boot state and the certificates that verified the boot, so a different boot chain verified by the same certificates, including an older signed component with a known bug, measures the same way. That is the kind of gap bitpixie uses on Windows, and a PIN closes it. --recovery-key enrolls a computer-generated recovery key in another slot, which you store offline.

Failure modes

• Trusting TPM-only on a laptop. It protects against someone who pulls the drive and stops there. Against anyone who boots the stolen machine with a sniffer or a bitpixie kit, it hands over the key.
• Not knowing where the recovery key is. A firmware update, a TPM clear or a motherboard repair can trigger BitLocker recovery. Without the 48-digit key the data is gone. Find it before you need it.
• Leaving the recovery key in a cloud account you do not want subpoenaed. Device encryption's Microsoft account upload is convenient and reachable by legal process. Same consideration for FileVault's iCloud option.
• Using sleep. The key stays in RAM, and on BitLocker resume from sleep skips the PIN. Hibernate or shut down when travelling.
• Assuming a local account means encrypted. Device encryption with only local accounts stays in the suspended clear-key state until a recovery key is backed up.
• "Used space only" on a drive that held plaintext. Deleted files sit in free space unencrypted until overwritten. Choose "Encrypt entire drive" on any drive that ever held unencrypted data.
• Hidden volumes on SSDs, in synced folders, or created with VeraCrypt 1.26.6 to 1.26.28 in file containers. Each one breaks the conditions deniability rests on.
• Updating VeraCrypt system encryption carelessly. Windows feature updates and the move from 2011 to 2023 Secure Boot certificates touch the boot loader; VeraCrypt's own notes warn about stale Rescue Disks and boot manager backups. Keep VeraCrypt current before a feature update.
• Expecting FDE to stop malware. Unlocked is unlocked. Endpoint protection and patching cover that threat.
• Weak passphrases. Argon2id and PBKDF2 slow guessing; they cannot rescue a password from a breach list. Use a long random passphrase from a password manager, and memorise the one that unlocks the disk.

Verdict by OS and threat level

So, VeraCrypt or BitLocker? On a Windows system drive, BitLocker with a startup PIN: it is maintained by the OS vendor, survives Windows updates, and gets TPM anti-hammering for a short PIN. VeraCrypt earns its place for portable drives, for volumes that must open on three operating systems, and for hidden volumes. BitLocker or FileVault? FileVault's default is the stronger one; BitLocker matches it once the PIN is added. And on Linux, LUKS2's defaults are already good, so the decision is whether you trade the boot passphrase for a TPM, and on a laptop the answer is to keep a PIN in the loop.