Topic 8 · Deep Dive

8.2 Full-Disk, File, and Message Encryption Basics

Full-Disk Encryption: Locking the Box

Full-disk encryption (FDE) defends data at rest against physical extraction: pull the drive from a stolen laptop and you inherit only ciphertext. BitLocker seals its volume master key to the TPM -- the chip encrypts the key to a set of PCR measurements of firmware and boot files, so the key unseals only if the boot chain is unaltered; a modified bootloader or a USB boot attempt fails measurement and demands the recovery key. Add a startup PIN or keyfile so possession of hardware alone never unlocks the volume. On Linux, LUKS2 stores a header with keyslots, each unlocking an Anti-Forensic Splitter-protected master key; use a long passphrase and argon2id. The standing caveat: FDE does nothing while the machine is powered on and unlocked -- that territory belongs to sleep modes, DMA protection, and screen locks.

File-Level Encryption: Per-Payload Control

FDE protects a machine, not a document once it leaves the machine. Encrypting individual payloads with age or GPG keeps data protected through cloud sync, email, USB sticks, and shared drives, because the ciphertext is self-contained: decryption requires the recipient's key, not the sender's disk state. age wraps one random file key to multiple recipients via X25519 or to a passphrase via scrypt; GPG does the same with RSA/ECC keys. VeraCrypt containers give the same property to a folder tree. Per-file keys also enable selective disclosure -- hand over one document's key, never a whole disk secret.

Message E2EE: The Server Never Holds the Key

End-to-end encryption is a statement about key custody, not about algorithms: only the endpoints hold message keys, and the relay server sees ciphertext plus metadata. The Signal protocol gives each conversation its own symmetric root chain and its Double Ratchet, which derives fresh chain keys per message so a single leaked key can neither read history nor future traffic. "Encrypted" chat platforms that hold server-side keys are not E2EE -- they provide transport and at-rest encryption, and the operator can still read everything. Note what E2EE never hides: who talked to whom, and when.

Stacking the Layers

The three mechanisms compose and are not redundant: FDE under everything, file-level encryption for anything that leaves a device, and E2EE for anything that transits someone else's servers. Enable FDE on every laptop on day one; it is the only layer that survives full-device theft.

Architecture Diagram

at rest: disk locked disk (FDE) TPM seal + startup PIN at rest: file encrypted file (age / GPG) cloud or USB in transit: E2EE sender E2EE envelope receiver relay server stores and forwards ciphertext only; keys stay on devices
Three independent layers: the disk unlocks only via TPM state, files carry their own ciphertext, and E2EE messages never expose keys to the server.

Key Takeaways

« Back to Topic 8« 8.1 / 8.3 »