Every major operating system ships with full-disk encryption capability: LUKS (Linux Unified Key Setup) on Linux, FileVault on macOS, and BitLocker on Windows. Phones have shipped with encryption enabled by default for years — Android since version 6.0 for most devices, iOS since version 8. Despite broad deployment, there's widespread confusion about what these systems actually do.
What Full-Disk Encryption Is
Full-disk encryption (FDE), more precisely called full-volume encryption in modern implementations, encrypts all data written to storage media. Every sector on disk is encrypted; every read decrypts the data, every write re-encrypts it. The encryption key is stored in memory only while the system is running and unlocked. When the device is powered off or locked (depending on configuration), the key is cleared from memory, and the disk contents are opaque without the correct credentials.
The cryptographic backbone is symmetric encryption. Modern implementations use AES-XTS (XTS mode of AES), specifically designed for disk encryption because it doesn't require an IV transmitted alongside each sector — the sector number itself serves as tweak input. AES-128-XTS or AES-256-XTS are standard choices; the difference in practical security is negligible given current factoring capabilities, but AES-256-XTS is common for regulatory compliance.
What It Actually Protects Against
The threat model for FDE is specific: a powered-off device falls into the wrong hands. A stolen laptop, a seized device, a phone found on the street — if the disk is encrypted and the attacker doesn't have your passphrase or PIN, the data is protected.
This is genuinely valuable. Without encryption, removing a laptop's storage drive and reading it directly bypasses any OS-level password. With encryption, the raw storage media is ciphertext and is not recoverable without the key.
A powered-off encrypted device in an attacker's hands. That's the threat it solves. Everything else — a running system, a logged-in system, a compromised OS — is outside its scope.
What It Does Not Protect Against
FDE provides no protection for a running, unlocked system. Once you log in, the encryption key is in memory and the file system is decrypted. Malware running on your system, an attacker with remote access, or anyone who sits down at your unlocked computer has full access to your data — the same access they'd have on an unencrypted system.
Specific threats that FDE doesn't address:
- Cold boot attacks — DRAM retains charge briefly after power loss. Sophisticated attackers can cool RAM modules and read encryption keys out of memory seconds to minutes after power-off. This attack has been demonstrated in research and requires physical access immediately after shutdown. Mitigations exist (memory encryption in modern CPUs, key scrubbing on shutdown) but are not universally deployed.
- Evil maid attacks — An attacker with physical access can modify the bootloader before you unlock the system, inserting code that captures your passphrase when you next enter it. FDE on its own doesn't prevent this; Secure Boot and measured boot (TPM-based) are the mitigations.
- Running system access — Law enforcement presenting a device while unlocked, malware, or anyone with your credentials can read your data normally.
- Cloud sync — If your encrypted laptop syncs to iCloud, Google Drive, or OneDrive, the plaintext of your files exists on those servers regardless of disk encryption.
LUKS, FileVault, and BitLocker: How They Differ
| Property | LUKS (Linux) | FileVault (macOS) | BitLocker (Windows) |
|---|---|---|---|
| Cipher | AES-XTS (configurable) | AES-XTS-256 | AES-XTS-128 or 256 |
| Key storage | LUKS header on disk; passphrase-derived | Wrapped with user password; recovery key to Apple optional | TPM + PIN, or TPM-only, or password |
| Recovery key escrow | Not escrowed (by default) | Optional iCloud escrow (Apple can receive) | Optional Azure AD / Microsoft account escrow |
| TPM integration | Available (via systemd-cryptenroll) | T2 / Apple Silicon chip | Native; TPM-only default on many OEMs |
| Audit / open source | ✓ Fully open | ✗ Proprietary | ✗ Proprietary |
A Note on BitLocker's TPM-Only Mode
Many Windows OEM devices ship with BitLocker configured to use the TPM alone, without a PIN. This means the encryption key is automatically released by the TPM at boot — no passphrase required. The device boots to the login screen without prompting for a decryption credential.
Against a powered-off theft scenario, this is adequate: the TPM won't release the key without the correct PCR (Platform Configuration Register) measurements, meaning a modified bootloader won't unlock the disk. But it provides no protection against someone who can power on the device and attack the login screen — which is a weaker guarantee than passphrase-protected encryption.
For stronger protection, add a BitLocker PIN (pre-boot authentication). This requires both the TPM and a PIN at every boot, preventing automatic unlock.
The Recovery Key Problem
Both FileVault and BitLocker offer to escrow your recovery key with Apple or Microsoft respectively. This is convenient — if you forget your passphrase, Apple or Microsoft can help you recover access. It also means that Apple or Microsoft possess your encryption recovery key and can be compelled to produce it under lawful process.
If you escrow your recovery key with Apple or Microsoft, your disk encryption is only as strong as Apple's or Microsoft's resistance to legal compulsion — not the strength of AES-256-XTS. For most users, the convenience trade-off is worth it. For high-risk users, it isn't.
LUKS on Linux, by default, keeps keys entirely local. There is no escrow unless you configure one. The trade-off is that lost passphrases mean genuinely lost data — there is no fallback.
Mobile: iOS and Android
Mobile encryption has distinct characteristics worth understanding. On iOS, the file system is encrypted at rest and Apple does not have access to the encryption key (which is derived from your device passcode). However, certain data classes are accessible when the device is unlocked or after first unlock — the "After First Unlock" protection class, used by apps by default, retains keys in memory after the first unlock until next reboot. Only "Complete Protection" class data (used for some email, but opt-in for apps) is fully inaccessible after lock.
Android's implementation varies more by manufacturer and Android version. Full-disk encryption has been replaced by file-based encryption in recent versions, which allows different files to be encrypted with different keys at different protection levels.
The practical implication: a phone that's been unlocked at least once, even if currently locked, retains more decryptable data than a phone that's been powered off entirely. For maximum protection, power off rather than lock before border crossings or situations where device seizure is anticipated.
Enabling FDE: A Quick Reference
- macOS: System Settings → Privacy & Security → FileVault. Enable; store recovery key yourself (don't escrow to Apple if you're security-conscious). Requires logout and background encryption pass.
- Windows: Search for "BitLocker." Pro/Enterprise editions get full BitLocker; Home editions get "Device Encryption" which has fewer options. Enable and back up recovery key to a password manager, not to your Microsoft account.
- Linux: Enable LUKS during OS installation (it's significantly harder to add after the fact). Use a strong passphrase — LUKS with a weak passphrase provides minimal real protection because the header is attackable offline.
- iOS/Android: Both encrypt by default. Set a strong PIN (6+ digits minimum; alphanumeric if your threat model warrants it) — the device passphrase is what protects the encryption key.
Full-disk encryption is worth enabling on every device you own. The performance overhead on modern hardware is negligible. The protection against the most common physical access scenarios — lost or stolen devices — is substantial. Just understand that it's one layer in a defense-in-depth approach, not a complete answer to data security.
For communication security specifically, FDE protects locally stored messages, but end-to-end encryption is what protects messages in transit — and they operate independently of each other.