Whether you are protecting a database at rest, securing traffic crossing a network, or ensuring that a message cannot be tampered with in transit, every scenario demands a deliberate choice. This guide walks through the full landscape of cryptographic solutions, from foundational concepts to advanced techniques, in a connected and practical way.
Understanding What You Are Protecting: The Three States of Data
Before selecting any cryptographic control, you must first understand the state of the data you intend to protect. Data does not sit still — it moves, it rests, it gets processed — and each state carries its own vulnerabilities.
- Data at rest is data held in persistent storage: hard drives, SSDs, USB drives, database files. A stolen disk with no encryption is an open book.
- Data in transit (also called data in motion) is data travelling across a network. Unencrypted traffic can be intercepted by anyone with access to the path between sender and receiver.
- Data in use (also called data in processing) is data temporarily held in volatile memory — RAM, CPU registers, and cache — while being actively worked on. This is the hardest state to protect.
┌─────────────────────────────────────────────────────────────┐
│ DATA LIFECYCLE │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │
│ │ AT REST │────▶│ IN USE │────▶│ IN TRANSIT│ │
│ │ (Disk/SSD) │ │ (RAM/Cache) │ │ (Network) │ │
│ └──────────────┘ └──────────────┘ └───────────┘ │
│ │ │ │
│ FDE / Volume / TLS / IPsec / │
│ File Encryption WPA / HMAC │
└─────────────────────────────────────────────────────────────┘
Understanding these three states is the starting point for everything that follows. Encrypting a database but leaving network traffic unprotected — or vice versa — creates gaps that attackers can exploit.
The Core Problem: Why We Combine Symmetric and Asymmetric Encryption
Encryption that protects large volumes of data is called bulk encryption. Here, the choice of algorithm matters enormously. Asymmetric algorithms like RSA and ECC use key pairs (public and private keys) and are powerful for key exchange and digital signatures — but they carry high computational overhead. Encrypting gigabytes of disk data or a continuous stream of network packets with an asymmetric cipher is impractically slow.
Symmetric ciphers like AES (Advanced Encryption Standard), on the other hand, are extremely fast and well-suited to bulk encryption. The problem is key distribution: a symmetric key must be shared between parties, and the more people who know it, the weaker its confidentiality becomes.
The solution used by virtually every modern cryptographic system is a hybrid approach — combine the speed of symmetric encryption with the secure key distribution of asymmetric encryption:
┌─────────────────────────────────────────────────────────────┐
│ HYBRID ENCRYPTION MODEL │
│ │
│ ┌─────────────┐ ┌─────────────────────────────────┐ │
│ │ Asymmetric │ │ Symmetric (AES-256) │ │
│ │ Key Pair │ │ │ │
│ │ (RSA/ECC) │ │ Encrypts the actual data │ │
│ └──────┬──────┘ └────────────────┬────────────────┘ │
│ │ │ │
│ Public key encrypts ◀────────────── DEK (Data Enc. Key) │
│ Private key decrypts │ │
│ │ │ │
│ └──────────── KEK ──────────────┘ │
│ (Key Encryption Key) │
└─────────────────────────────────────────────────────────────┘
The terminology here is important:
- KEK (Key Encryption Key): The asymmetric private key (or derived key) used to encrypt and protect the symmetric key.
- DEK (Data Encryption Key): The symmetric key used to encrypt the actual data.
The full scheme works like this:
- The user generates an asymmetric key pair (RSA or ECC). The private key becomes the KEK, encrypted so that the user must authenticate to use it.
- The system generates a random symmetric secret key — the DEK — using a cipher such as AES-256.
- The DEK encrypts the target data.
- The DEK itself is then encrypted using the public portion of the KEK.
- To access the data, the user authenticates, the private key decrypts the DEK, and the DEK decrypts the data.
This design means the actual encryption key never travels in the clear. Symmetric speed handles the data; asymmetric security handles the key.
Protecting Data at Rest: Disk, Volume, and File Encryption
With the hybrid model in mind, the question becomes: at what level should encryption be applied to stored data? The answer depends on what you are protecting, who needs access, and how granular your control needs to be.
Full-Disk and Partition Encryption
Full-disk encryption (FDE) encrypts the entire contents of a storage device — not just the user files, but also metadata areas and free space. Its primary use case is physical theft: a stolen encrypted disk cannot be mounted on another machine and read without the decryption key.
Many modern drives implement this natively as self-encrypting drives (SEDs) — HDDs, SSDs, or USB drives with a built-in cryptoprocessor in the firmware. Because keys are stored in the hardware, they are never directly exposed to the OS.
Storage devices can also be split into partitions, each formatted separately. Some encryption products can target individual partitions with different keys:
┌──────────────────────────────────────────┐
│ PHYSICAL DISK │
│ │
│ ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│ │ BOOT │ │ SYSTEM │ │ DATA │ │
│ │Partition │ │Partition │ │Partition│ │
│ │(no enc.) │ │(no enc.) │ │(AES-256 │ │
│ └──────────┘ └──────────┘ └─────────┘ │
│ │
│ Boot/system contain only standard OS │
│ files; data partition is protected │
└──────────────────────────────────────────┘
Volume and File Encryption
A volume is how the OS perceives a storage resource — whether it is a partition, a RAID array, or a removable disk. Volume encryption is typically implemented in software rather than firmware. Microsoft's BitLocker and Apple's FileVault are the most common examples. These products may or may not encrypt free space and file metadata, depending on configuration.
File encryption operates at the finest granularity — applying encryption to individual files or folders. Microsoft's Encrypting File System (EFS) is an example, requiring the volume to be formatted with NTFS.
The levels form a clear hierarchy:
HIGH GRANULARITY (more control, more complexity)
▲
│ File / Folder Encryption (EFS)
│ Volume Encryption (BitLocker, FileVault)
│ Partition Encryption (selective, per-key)
│ Full-Disk Encryption (FDE / SED)
▼
LOW GRANULARITY (simpler, but coarser access control)
Lower levels offer simplicity but make multi-user access control harder. Higher levels allow fine-grained permissions but require more management overhead. The right choice depends on your threat model and access requirements.
A key supporting technology across all levels: if the device has a TPM (Trusted Platform Module) or HSM (Hardware Security Module), the encryption keys can be stored and protected in hardware, significantly raising the bar for key extraction.
Protecting Data in Databases
Structured databases present a unique challenge. Data is ultimately stored as files on disk, but access is mediated through a DBMS (Database Management System) running SQL. Encryption applied at the OS level protects the files but does not necessarily protect the data within them from a privileged database user. More targeted database-level controls are usually needed.
Encryption can be applied at three meaningful levels inside a database:
Database-Level (Transparent Data Encryption)
Transparent Data Encryption (TDE) encrypts data at the page level — the unit the database engine uses to transfer data between disk and memory. From the application's perspective, it is transparent: queries work normally, but every page is encrypted on disk.
- Protects against theft of the underlying storage media.
- Also encrypts database logs.
- Does not protect against a privileged DBA who has access to the running system — the data is decrypted in memory on demand.
Column/Cell-Level Encryption (Always Encrypted)
For secrets that even the DBA should not see, cell or column encryption applies encryption to specific fields within a table. SQL Server's Always Encrypted feature takes this further: the data remains encrypted even when loaded into memory. The plaintext decryption key is held by the client application — never by the DBMS itself.
┌──────────────────────────────────────────────────────────┐
│ DATABASE TABLE │
│ │
│ UserID │ Name │ Salary │ Department │
│──────────┼──────────┼────────────────────┼───────────────│
│ 001 │ Alice │ [xK7$mP#2rQ9vL] │ Finance │
│ 002 │ Bob │ [9vL#mK7$rQ2xP] │ Engineering │
│ 003 │ Carol │ [rQ2$xP9vK7#mL] │ HR │
│ │
│ Salary column encrypted: DBA sees only ciphertext. │
│ Client app holds the key — only it can decrypt. │
└──────────────────────────────────────────────────────────┘
This enforces a critical principle: separation of duties between the database administrator and the data owner. This separation is especially important for privacy compliance.
Record-Level Encryption
The most granular option is record-level encryption, where each row in a table is protected by a separate key pair. Consider a health insurer's database holding protected health information (PHI): each customer could be identified by their own key pair, with their records encrypted independently. Even an authorized user of the database can only decrypt the rows for which they hold the key. This enables fine-grained, compliance-driven access control.
┌────────────────────────────────────────────────────┐
│ RECORD-LEVEL ENCRYPTION │
│ │
│ Row 1 ──── encrypted with Key_A (Patient A) │
│ Row 2 ──── encrypted with Key_B (Patient B) │
│ Row 3 ──── encrypted with Key_C (Patient C) │
│ │
│ Access to Key_A ≠ access to Key_B or Key_C. │
└────────────────────────────────────────────────────┘
Protecting Data in Transit: Transport Encryption and Key Exchange
When data moves across a network, the threat model shifts. An attacker does not need physical access — they only need to be able to observe or intercept packets. Transport encryption solutions address this:
- WPA (Wi-Fi Protected Access) — secures wireless network traffic.
- IPsec — encrypts traffic between two endpoints across a public or untrusted network, forming the basis of VPNs.
- TLS (Transport Layer Security) — protects application-layer data such as web (HTTPS), email, and other services.
As with data at rest, transport encryption uses a hybrid model. Asymmetric encryption does not encrypt the traffic itself — it protects the exchange of the symmetric session key. The mechanism is called a digital envelope:
ALICE BOB
│ │
│ 1. Obtains Bob's public key (via cert) │
│ │
│ 2. Encrypts message with symmetric │
│ session key (AES) │
│ │
│ 3. Encrypts session key with Bob's │
│ public key │
│ │
│──── [ Ciphertext + Encrypted Session Key ]───▶│
│ │
│ 4. Bob decrypts session │
│ key with private key │
│ │
│ 5. Bob decrypts message │
│ with session key │
│ │
To ensure integrity and authenticity — not just confidentiality — transport encryption also uses a HMAC (Hash-based Message Authentication Code), which combines the session key with a hash of the message. Alternatively, the symmetric cipher may use an Authenticated Encryption (AE) mode, which provides both confidentiality and integrity in a single operation.
Perfect Forward Secrecy: Protecting the Past from Future Compromise
The digital envelope approach has a significant weakness: if the server's private key is ever compromised, a recorded past session can be decrypted retroactively. An attacker who has been recording encrypted traffic can simply wait until the key leaks, then replay the decryption.
Perfect Forward Secrecy (PFS) solves this by ensuring that session keys are ephemeral — generated fresh for each session and never derived from the server's long-term private key. The mechanism that makes this possible is Diffie-Hellman (D-H) key agreement.
The elegance of Diffie-Hellman is that two parties can independently derive the same shared secret over a public channel, without ever transmitting the secret itself:
ALICE PUBLIC BOB
│ │
│── Agree on p=23, g=9 (public values) ──────────│
│ │
│ Picks secret a=5 Picks secret b=3 │
│ │
│ Computes A = g^a mod p │
│ A = 9^5 mod 23 = 8 │
│ │
│──────────────── sends A=8 ─────────────────────▶│
│ │
│◀────────────── sends B=16 ──────────────────────│
│ │
│ B = g^b mod p │
│ = 9^3 mod 23 = 16 │
│ │
│ s = B^a mod p s = A^b mod p │
│ = 16^5 mod 23 = 6 = 8^3 mod 23 = 6 │
│ │
│ SHARED SECRET s=6 (never transmitted) │
│ │
│ Mallory knows p, g, A, B — cannot find s │
│ without solving the discrete logarithm problem │
Because the session key is derived from ephemeral values (a and b), discarding them after the session means the session key is gone forever — even if the server's long-term key is later compromised. This also means that compromising one session's key does not compromise any other session.
- DHE (Diffie-Hellman Ephemeral): Uses modular arithmetic as shown above.
- ECDHE (Elliptic Curve DHE): Uses elliptic curve mathematics for the same result with greater efficiency. ECDHE is the preferred implementation in modern TLS.
Salting and Key Stretching: Hardening Password-Derived Secrets
Cryptographic keys must be unpredictable — high in entropy. When a key or hash is derived from a user-chosen password, the entropy is almost always low: people pick short, ordered, memorable passwords. Two techniques address this vulnerability directly.
Salting
Cryptographic hash functions are widely used to store passwords. A hash is a one-way function: you cannot reverse it to recover the original password. However, an attacker with access to a stolen password file can run a brute-force attack (trying every combination) or a dictionary attack (hashing common words and comparing), especially using precomputed rainbow tables that map common passwords to their hashes.
Salting defeats precomputed attacks by adding a unique random value to the password before hashing:
WITHOUT SALT:
┌───────────┐ SHA ┌─────────────────────────────────┐
│"password" │────────▶│ 5f4dcc3b5aa765d61d8327deb882cf99│
└───────────┘ └─────────────────────────────────┘
(Same input always gives same hash — rainbow tables work)
WITH SALT:
┌────────────────────────────┐ SHA ┌───────────────┐
│ "xQ7!k2mP" + "password" │────────▶│ (unique hash) │
└────────────────────────────┘ └───────────────┘
(Unique salt per user → unique hash even for same password)
The salt is stored alongside the hash in plaintext — it is not secret. Its value is purely to force attackers to recompute hashes from scratch for each individual password, making precomputed tables useless.
Key Stretching
Key stretching goes further: it takes the salted password and runs it through thousands of rounds of hashing, producing a longer and more disordered key. This does not make the underlying password harder to guess in theory, but it multiplies the computation required for each guess in practice — turning a fast attack into a slow one.
PBKDF2 (Password-Based Key Derivation Function 2) is the most widely used standard for key stretching, and it forms a core part of Wi-Fi Protected Access (WPA). Other algorithms such as bcrypt and Argon2 serve the same purpose.
Password + Salt
│
▼
[Hash #1]──▶[Hash #2]──▶[Hash #3]──▶ ... ──▶[Hash #10,000]
│
▼
Stretched key (far slower to brute-force, same security property)
Together, salting and key stretching transform a weak human-chosen password into a form that is significantly more resistant to offline attack.
Blockchain: Cryptography Applied to Distributed Trust
Blockchain represents one of the most interesting applications of cryptographic principles at scale. At its core, a blockchain is an expanding list of records — called blocks — where each block is cryptographically linked to the one before it.
Each block contains:
- Transaction data
- A timestamp
- The hash of the previous block
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ BLOCK 1 │ │ BLOCK 2 │ │ BLOCK 3 │
│ │ │ │ │ │
│ Data: [Tx A] │ │ Data: [Tx B] │ │ Data: [Tx C] │
│ Timestamp: T1 │ │ Timestamp: T2 │ │ Timestamp: T3 │
│ Prev Hash: 0000 │──▶│ Prev Hash: H(B1) │──▶│ Prev Hash: H(B2) │
│ Hash: H(B1) │ │ Hash: H(B2) │ │ Hash: H(B3) │
└───────────────────┘ └───────────────────┘ └───────────────────┘
Tampering with Block 1 changes H(B1),
which invalidates Block 2's stored prev hash,
which cascades and invalidates every subsequent block.
Because altering any historical block would change its hash and break the chain from that point forward, the entire ledger is tamper-evident by design. Crucially, this ledger is decentralized — distributed across a peer-to-peer network with no single controlling node. Every participant can verify every transaction equally. This removes single points of failure and eliminates the need to trust any central authority.
Blockchain technology has broad applications beyond cryptocurrency: financial transactions, legal contracts, intellectual property protection, online voting systems, identity management, and secure data storage — anywhere that transparency, integrity, and decentralized trust matter simultaneously.
Obfuscation: When Hiding Is Part of the Strategy
Cryptographic confidentiality is not the only way to protect sensitive data. A class of techniques known as obfuscation makes data difficult to find, interpret, or use — even without traditional encryption. While security by obscurity alone is always insufficient, obfuscation serves legitimate and important roles, particularly around privacy and de-identification.
Steganography
Steganography (from the Greek for "hidden writing") conceals a message inside an unexpected carrier — for example, embedding data within the pixels of an image or the timing of network packets. The carrier file is called the covertext. The hidden message may itself be encrypted before embedding, providing confidentiality on top of concealment. Steganography can also provide integrity and non-repudiation: for instance, a watermark embedded in a printed document can identify the printer, the time of printing, and whether the document is genuine or forged.
Data Masking
Data masking replaces all or part of a sensitive field's contents with substitute characters — for example, replacing every digit of a credit card number with x, yielding xxxx-xxxx-xxxx-1234. Partial masking can preserve metadata useful for analysis (such as a telephone dialling prefix) while protecting the subscriber number. Masking can also preserve the format of the original field (e.g. keeping numeric characters where numbers were). Masking is irreversible — the original value is gone.
Tokenization
Tokenization replaces a sensitive value with a randomly generated token. Unlike masking, the original value is preserved — stored in a separate, secured token vault or token server, isolated from the production database. Authorized applications can retrieve the original value from the vault when necessary.
PRODUCTION DATABASE TOKEN VAULT (separate, secured)
┌──────────────────────┐ ┌──────────────────────────────┐
│ CardNumber │ │ Token │ Real Value │
│ TK-8472-2910-XJQP │◀───▶│ TK-8472... │ 4111111111111 │
│ TK-3391-7654-MKRW │ │ TK-3391... │ 5500000000000 │
└──────────────────────┘ └──────────────────────────────┘
(Token has no mathematical (Only retrieved
relation to real value) by authorized query)
Tokenization is used as an alternative to encryption in regulated environments for an important regulatory reason: an encrypted field is still considered the same data as the original (just encoded), whereas a token has no mathematical relationship to the original value and may be treated differently under certain compliance frameworks.
Both data masking and tokenization serve the purpose of de-identification — removing or obscuring personal data from datasets so they can be shared, analyzed, or stored without exposing the underlying personal information.
Putting It All Together: Choosing the Right Control
Every cryptographic decision flows from the same starting questions: What is the state of the data? Who are the likely adversaries? What level of access control do you need? The table below summarizes the primary controls mapped to each concern:
┌─────────────────────────────────────────────────────────────────────┐
│ CRYPTOGRAPHIC CONTROL SUMMARY │
├─────────────────┬───────────────────────────────────────────────────┤
│ Concern │ Solution │
├─────────────────┼───────────────────────────────────────────────────┤
│ Bulk data enc. │ Symmetric cipher (AES-256) │
│ Key distribution│ Asymmetric cipher (RSA/ECC) wraps symmetric key │
│ Disk theft │ FDE / SED / Volume encryption(BitLocker/FileVault)│
│ DB media theft │ Transparent Data Encryption (TDE) │
│ DBA separation │ Always Encrypted (cell/column level) │
│ Fine-grained DB │ Record-level encryption (per-row key pairs) │
│ Network traffic │ TLS / IPsec / WPA │
│ Key replay risk │ Perfect Forward Secrecy (DHE / ECDHE) │
│ Password hashes │ Salting + Key stretching (PBKDF2) │
│ Tamper evidence │ Blockchain (cryptographic chaining) │
│ Concealment │ Steganography │
│ De-identification│ Data masking (irreversible) / Tokenization (rev.)│
└─────────────────┴───────────────────────────────────────────────────┘
The most common mistake in deploying cryptographic controls is treating them as isolated choices. In practice, they are layered and interdependent: a database protected by TDE still needs TLS on the connection between client and server; a file encrypted with AES still needs a proper KEK/DEK scheme to protect the key itself; passwords stored with salted hashes still benefit from key stretching to slow offline attacks.
Cryptography is not the presence or absence of a lock — it is a system of interlocking controls, each closing a gap that another leaves open. Understanding how these layers connect, and why each one exists, is what separates a security professional who implements cryptography from one who truly understands it.