Encryption in Practice - Protecting Your Data on Every OS, From Disk to Documents

Encryption is the only security control that keeps working after every other one has failed. When a laptop is stolen, when a backup drive is lost, when a cloud account is subpoenaed, the question that decides everything is whether the data was ciphertext at the moment it left your control. Firewalls, antivirus, and passwords are gates. Encryption is the material your data is made of.

This article is a practical tour of encryption across the platforms you actually use: how full-disk encryption works on Linux, macOS, Windows, and phones, what it genuinely protects against, where it stops, and the complementary techniques, including second-layer file-level encryption, that cover the gaps.

The Fundamentals: What Encryption Is Actually Doing

Three ideas explain almost everything in this article.

Data has states. Data is at rest (on a disk, in a backup, on a phone), in transit (crossing a network), or in use (being processed). Each state has its own encryption tools, and confusing them is the most common security mistake. People assume an encrypted disk protects their uploads, or that HTTPS protects their laptop. It does not. Every state needs its own answer.

Symmetric ciphers do the heavy lifting. Key management decides who wins. Modern drives and files are encrypted with symmetric ciphers, AES most commonly, operating in modes like XTS for storage or GCM for files. These ciphers are not the weak point. What separates a good setup from a bad one is key management: how the key is derived from your passphrase, where it is stored, when it is in RAM, and who can compel its release. A weak passphrase in front of AES-256 is a weak passphrase. The cipher does not save you.

Passphrases go through a KDF before they become keys. A key derivation function (Argon2id in LUKS2, PBKDF2 with high iteration counts in VeraCrypt) turns your passphrase into an encryption key and makes each guessing attempt expensive. Passphrase length matters more than character trickiness, because each added word multiplies the attacker's cost. Ten random characters and five random words are in different leagues. The latter wins.

One more principle runs through the rest of this article. Encryption protects against offline access to the medium. It does not protect against a running system that already has the keys.

Full-Disk Encryption, OS by OS

Full-disk encryption (FDE) is the foundation layer everywhere. It keeps the storage medium as ciphertext when the machine is powered off. Here is the state of the art on each platform in 2026.

Linux: LUKS (dm-crypt)

LUKS is the standard on-disk format for dm-crypt, the kernel's device-mapper encryption layer. LUKS2 is the current format. It uses Argon2id for key derivation, which is memory-hard and far more resistant to GPU cracking than the older PBKDF2 default of LUKS1.

• Any mainstream distribution offers whole-system encryption at install time. Take it. Encrypting only the home partition is a legacy pattern that leaves swap, logs, and temp files in plaintext.
• The LUKS header is the single point of failure. If it is damaged, the correct passphrase unlocks nothing. Back it up with cryptsetup luksHeaderBackup and store that backup encrypted and off-site. The header contains everything an attacker needs for an offline brute force.
• Use multiple key slots: a daily passphrase, plus a long recovery passphrase held offline.
• On an SSD, wear leveling can leave plaintext that was written before encryption in flash cells outside the encrypted area. Encrypt from day one.

macOS: FileVault

FileVault is Apple's built-in volume encryption, built on APFS native encryption (XTS-AES-128). On Apple Silicon, storage is encrypted at the hardware level whether or not FileVault is on. FileVault controls whether those keys are released without your password.

Turn it on in System Settings, under Privacy and Security, then FileVault. Then make two deliberate choices:

• Recovery method: keep a local recovery key offline if your threat model includes account compromise. The iCloud recovery option puts that key where an account takeover can reach it.
• Sleep behavior: some power states keep the volume key available. The destroyfvkeyonstandby setting tells FileVault to discard the key on standby. Confirm what your macOS version actually does before you rely on it. Apple Silicon power states are not the same as older Intel Macs.

Boot protection differs by hardware. On an Intel Mac, set a firmware password so the machine cannot be started from external media. On Apple Silicon there is no firmware password. Leave Startup Security at Full Security. Starting from external media already requires the owner password.

Windows: BitLocker

BitLocker is Microsoft's volume encryption (XTS-AES). It binds the volume key to the TPM so the disk unlocks only when the measured boot state is intact.

• Do not accept the TPM-only default. With TPM-only, the disk auto-unlocks on any clean boot. Set a pre-boot PIN under Group Policy, in BitLocker Drive Encryption, then Require additional authentication at startup. TPM plus PIN means the secret is not stored on the machine.
• Store the 48-digit recovery key offline if your threat model includes a compelled Microsoft account. On Home editions the key is often saved to that account during setup. Know where yours went before you rely on BitLocker.
• Keep the Windows Recovery Environment (WinRE) updated. That environment has been the soft spot. Microsoft's STORM team (Security Testing and Offensive Research) disclosed the BitUnlocker flaws in WinRE: CVE-2025-48800, CVE-2025-48003, CVE-2025-48804, and CVE-2025-48818. On systems that were fully patched at the time, those bugs allowed access to BitLocker volumes without the user's credentials. Microsoft patched them in July 2025. A later WinRE bypass, YellowKey (CVE-2026-45585), affected Windows 11 24H2, 25H2, and 26H1, plus Windows Server 2025, and was patched in June 2026. FDE has an attack surface. Treat the recovery environment as part of it.

iPhone

iOS encrypts files individually. Per-file keys sit in a hierarchy managed by the Secure Enclave, grouped into protection classes. Two states matter:

• Before first unlock (BFU), after a reboot: nearly all user data is cryptographically inaccessible. This is the strongest state a seized phone can be in.
• After first unlock (AFU): class keys needed for normal use are available in memory for the rest of that boot. More of the phone becomes readable as you use it.

The passcode sits at the root of that hierarchy, and the Secure Enclave rate-limits guesses. Length is the whole game. A 6-digit PIN is within reach of a forensic lab. A long alphanumeric passphrase is not, on any practical timeline.

• Use an alphanumeric passcode, not a 4-digit or 6-digit code. The control is in Settings, under Face ID and Passcode.
• Turn on Erase Data after 10 failed attempts only if losing the contents of that phone is acceptable.
• Reboot before a situation where the phone might be taken. A powered-off phone is in BFU.
• Disable USB accessories while locked. Then decide about iCloud on purpose. Without Advanced Data Protection, backups, including message history, can be reached through the account. With Advanced Data Protection, those backups are end-to-end encrypted and the keys stay with you.

Android and GrapheneOS

Current Android encrypts user data by default, so a stock phone is already in decent shape when it is off. What still separates setups is the passphrase, and what happens if the phone is taken while it is on.

GrapheneOS, the hardened Android build for Pixel phones, is the strongest option in this category in 2026:

• Each user profile has its own encryption keys. A profile that is not running is inaccessible, which makes a separate profile a clean way to wall off sensitive data.
• Auto-reboot returns the device to BFU after a period of inactivity you choose. That closes the "seized while unlocked" gap more directly than anything in stock Android.
• Verified boot uses the A/B scheme, a Titan secure element, and a hardened memory allocator. The point of the stack is that a software compromise should not become a key-extraction bug.

On any Android, use a long passphrase, turn on auto-reboot where the OS offers it, and put the sensitive work in its own profile.

What FDE Protects and Where It Stops

FDE answers one question well: what happens if the medium is taken while it is powered off? A laptop in a stolen bag, with the machine shut down. A lost backup drive. A phone rebooted before a border crossing. In those cases the other person gets ciphertext.

The disk key is loaded into RAM at boot and stays there while the system runs.

• After you log in, processes running as you read the volume in plaintext. Malware on a live session does not care that the disk was encrypted at rest.
• A machine seized while running, asleep, or only screen-locked already has the key. The login prompt is a much weaker barrier than the cryptography.
• Suspend often unlocks on wake without asking for the disk passphrase again.
• Cold-boot and DMA attacks aim at this window: the key sitting in RAM of a machine that is still on.

FDE stays mandatory, and it is only the first layer. Shut down fully instead of sleeping when you travel, set a pre-boot PIN, and reboot phones. Those habits shrink the window. For the files that matter most, the next layer keeps them encrypted even while the session is open.

Second-Layer Encryption: Keeping Data Encrypted Inside the Session

Put the sensitive files in a vault that you unlock only while you are working, and lock again when you stop. Someone who gets past the lock screen, or malware already running as you, then finds ciphertext. While the vault is locked, its contents stay protected even on a compromised session.

This sits on top of FDE. FDE covers the powered-off machine. The vault covers the open session. Two open-source tools cover most of this job, and they have different shapes.

Cryptomator

Cryptomator encrypts each file and each filename on its own, then presents the vault as a virtual drive that decrypts on the fly. It is built for cloud sync. The folder that syncs contains only ciphertext. Locally you still work with ordinary files.

• It runs on Windows, macOS, and Linux, with mobile apps on iOS and Android and direct integration for the major cloud providers.
• There is no account and no server-side key. The master key is derived from your passphrase and stored encrypted inside the vault.
• Auto-lock closes the vault after inactivity.
• It fits day-to-day working files, synced folders, and anything you also open from a phone.

VeraCrypt

VeraCrypt is the audited successor to TrueCrypt. It encrypts a container file or a whole partition, then mounts that as a volume. An external drive can be encrypted the same way.

• The default key derivation uses hundreds of thousands of PBKDF2 iterations. RIPEMD-160 was removed in version 1.26. A Personal Iterations Multiplier lets you raise the cost of guessing further.
• Cipher choices include AES, Serpent, Twofish, Camellia, Kuznyechik, and ten cascades, for people who want a second cipher in case one of them fails later. The mode is XTS throughout.
• A keyfile stored on a separate USB stick means a stolen passphrase is not enough. That is the closest free-software equivalent to a second factor for data at rest.
• A hidden volume is a second volume, indistinguishable from free space inside the first, for the case where you can be compelled to reveal a passphrase. It is easy to damage. Writes to the outer volume can overwrite the hidden one unless you protect it while the outer volume is mounted.
• It fits archives, external drives, offline backups, and the smallest set of files you cannot afford to have open.

How They Fit Together

Using both is a reasonable split. Cryptomator for the files you sync and edit. A VeraCrypt container for the cold archive. The habit is the same either way, and it is the part that matters: the vault stays locked until you are working, then it closes. A vault that stays mounted all day is a folder with extra steps.

Backups, Cloud, and Transit

Disk and file encryption cover data at rest. Backups, cloud copies, and the network need their own decisions.

Backups. A backup is a copy that lives outside the machine, and it is often the copy that gets lost. An encrypted laptop whose backup disk is plaintext has given the data away. Copy the encrypted vault itself (a Cryptomator folder or a VeraCrypt container is still ciphertext), or use backup software that encrypts on the client before anything leaves. Then restore once, on purpose. An encrypted backup you have never restored is a hope, not a backup.

Cloud and sync. End-to-end encryption is the property that matters: the provider stores ciphertext and does not hold the key. Cryptomator gives you that for files on any cloud. Apple's Advanced Data Protection gives it to iCloud backups. A few providers offer it natively. Most do not. Without it, the provider can read the data, and so can anyone who compromises that provider or compels them. Choose the product for that property.

In transit. HTTPS, a VPN, and an encrypted messenger protect data while it moves. They do not replace anything above. An encrypted disk says nothing about your network traffic. A VPN encrypts the path from your machine to the VPN server. If the machine is already compromised, the VPN only hides the theft from the network.

Operational Hygiene

These controls are habits as much as software.

• Vaults locked by default, with auto-lock on, and nothing sensitive living outside them.
• A full shutdown, not sleep, before travel and border crossings. Phones rebooted so they are in BFU.
• A pre-boot PIN on BitLocker. An alphanumeric passcode on each phone.
• Recovery keys and LUKS headers stored offline, physically apart from the devices.
• Temp folders and Downloads cleaned on a schedule. Editors and browsers drop plaintext copies outside the vault.
• Backups encrypted by default, and a restore you have actually performed.
• The OS kept current, including WinRE. That is the component that has bitten BitLocker twice.

Quick-Start Checklist

Every device

• Full-disk encryption is on and you have checked it: LUKS from install, FileVault, BitLocker with a PIN, or a long phone passcode.
• The recovery key, and the LUKS header if you use Linux, is backed up offline and kept apart from the device.
• Intel Macs have a firmware password. Apple Silicon stays on Full Security. Other machines have a boot password where the firmware offers one.

Where the sensitive files live

• A Cryptomator vault for working files, with auto-lock on.
• A VeraCrypt container for archives and external drives, with the keyfile on separate media.
• The vault locked unless you are in it. Nothing sensitive outside.

Backups and cloud

• Backups are ciphertext: a copy of the vault, or a client that encrypts before upload. One restore has been tested.
• End-to-end encryption is on where the service offers it, including Advanced Data Protection.

When you travel

• The laptop is shut down, not asleep. The phone has been rebooted.
• GrapheneOS auto-reboot is on, or you reboot other phones yourself.

Sources and Further Reading

• BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets, Microsoft Security Blog. The STORM write-up from Black Hat USA 2025 and DEF CON 33.
• YellowKey: the WinRE BitLocker bypass, Eclypsium, on CVE-2026-45585.
• VeraCrypt, for PIM, keyfiles, and hidden volumes.
• Cryptomator, including the security architecture notes.
• cryptsetup, for LUKS2, Argon2id, and header backup.
• GrapheneOS usage, for encryption, auto-reboot, and profiles.
• Apple Platform Security, for FileVault, the Secure Enclave, data protection classes, and Advanced Data Protection.
• Lest We Remember: Cold Boot Attacks on Encryption Keys, Halderman et al., USENIX Security 2008.

Install VeraCrypt, Cryptomator, cryptsetup, and OS images only from the project's own site or its official repository. Check the published checksum or signature against the announcement on that same project, and treat a third-party mirror as untrusted.