CH6: Cryptography and Public Key Infrastructure

Introduction

Cryptography is the mathematical and technical foundation of information security. It transforms data into a form that is intelligible only to authorized parties, protects the integrity of information in transit and at rest, and provides the basis for trust in digital systems. Understanding how encryption works—and equally important, where its limitations lie—is essential for anyone designing or defending information systems.

This chapter moves beyond "use encryption" to explain how encryption actually protects data, what kinds of encryption exist, why organizations choose one over another, and how cryptographic systems fail when misconfigured or compromised. You will learn that cryptography is not a security silver bullet; it is one control in a layered defense, and its effectiveness depends on proper key management, correct implementation, and alignment with your organization's threat model.

Learning Objectives

After completing this chapter, you will be able to:

Distinguish between encryption, encoding, and obfuscation and explain why this distinction matters for security decisions.
Describe the mechanisms and operational differences between symmetric and asymmetric encryption, including their strengths and limitations.
Explain how hashing and salting protect sensitive data without enabling decryption, and identify forensic and security applications of hash functions.
Analyze the role of digital signatures in establishing authenticity and non-repudiation.
Evaluate Public Key Infrastructure as a trust model and explain the lifecycle of digital certificates.

6.1 Encryption Fundamentals

What Encryption Does and Does Not Do

Encryption transforms readable data—called plaintext—into an unreadable form called ciphertext using a mathematical algorithm and a secret key. Only someone with the correct key can reverse the process (decryption) and recover the plaintext. This is fundamentally different from encoding, which uses a publicly known method (such as Base64 or hexadecimal) to convert data into another format. Encoding is not security; it is not reversible only to authorized parties; it simply changes the representation of data.

Obfuscation occupies a middle ground: it obscures data in a way that requires effort or tools to reverse, but it is not cryptographically secure. Code obfuscation in software, for example, makes source code harder to understand, but a determined adversary with sufficient skill or tools can reverse the obfuscation. Security controls must never rely solely on obfuscation.

Encryption protects confidentiality—the property that information is not disclosed to unauthorized parties. Encryption alone does not provide integrity (assurance that data has not been altered), authenticity (assurance of the source's identity), or non-repudiation (assurance that the sender cannot deny having sent a message). These properties require additional cryptographic mechanisms such as hashing and digital signatures.

Common Misconception

Encryption is not magic. An encrypted database is still vulnerable to insider threats, misconfigurations that expose the decryption key, or attacks that bypass encryption by targeting the plaintext data in memory or during processing.

Symmetric Encryption

In symmetric encryption, both the sender and receiver share the same secret key. The sender encrypts the plaintext with this key, transmits the ciphertext, and the receiver decrypts it with the same key. This approach is fast, efficient, and mathematically straightforward.

Advanced Encryption Standard (AES) is the dominant symmetric cipher in modern systems. Approved by the U.S. National Institute of Standards and Technology (NIST), AES operates on fixed blocks of data (128 bits) and uses a shared key that is either 128, 192, or 256 bits long. AES-256 is the standard for protecting classified U.S. government information and is considered secure for decades. The computational effort required to break AES-256 by brute force (trying every possible key) is astronomically impractical.

The main challenge with symmetric encryption is key distribution: how do you securely share the secret key with the other party in the first place? If an attacker intercepts the key during transmission, all encrypted data is compromised. For a small number of parties with a secure out-of-band channel (a courier, a secure phone line), this is manageable. For internet-scale communication, it is not.

Analyst Perspective

When you audit data-at-rest encryption in an organization, always ask: Where is the encryption key stored? Who can access it? How is it rotated? A company with AES-256 encryption but keys stored in a plaintext configuration file has achieved encryption theater, not security.

Trace Alice's note and the shared key in Figure 6.1. This example uses AES in Galois/Counter Mode (AES-GCM), which combines encryption with an integrity check. A nonce is a value that must be unique for each encryption under a given key; the authentication tag lets the receiver detect changes.

Figure 6.1: Alice sends a confidential meeting note using a shared secret. Both endpoints already hold the same key; the network carries ciphertext, a nonce, and an authentication tag.

Text description for Figure 6.1

Alice and Bob establish the same secret key K through a protected setup process before this exchange. Alice's plaintext is Meet at 10:00. AES-GCM uses K and a unique nonce to produce ciphertext and an authentication tag. Alice sends those three outputs across the network. Bob uses K to verify the tag and recover the plaintext, rejecting the data if verification fails. The shared key stays at the endpoints.

Asymmetric Encryption

Asymmetric encryption, also called public-key cryptography, uses two mathematically related keys: a public key that can be shared and a private key that the owner protects. In public-key encryption, the sender encrypts with the recipient's public key, and the recipient decrypts with the corresponding private key. The sender must verify whose public key they are using. Digital signatures use separate signing and verification operations.

RSA (Rivest-Shamir-Adleman) is the most widely deployed asymmetric algorithm. RSA's security depends on the computational difficulty of factoring the product of two large prime numbers. A 2048-bit RSA key is considered secure against current and near-term future attacks. A 4096-bit key provides even greater assurance, though at a computational cost.

Elliptic Curve Cryptography (ECC) is a newer approach that achieves equivalent security with smaller key sizes. A 256-bit ECC key provides roughly the same security strength as a 3072-bit RSA key. ECC is increasingly common in mobile systems and modern protocols like TLS 1.3 because it is faster and requires less bandwidth.

Asymmetric operations are computationally expensive compared with symmetric encryption. RSA encryption also limits the size of each message. A hybrid approach combines public-key mechanisms for establishing or protecting keys with symmetric encryption for the bulk data.

Follow the public and private keys separately in Figure 6.2. The short-message example uses RSA with Optimal Asymmetric Encryption Padding (RSA-OAEP), a defined encryption scheme rather than a raw mathematical RSA operation.

Figure 6.2: Alice uses an authenticated copy of Bob's public key to encrypt a short note. Bob decrypts with his private key. Encrypting for Bob does not by itself establish Alice's identity.

Text description for Figure 6.2

Bob generates a public/private key pair. Alice obtains the public key and verifies its association with Bob through an authenticated source. She encrypts the short note Meet at 10:00 using RSA-OAEP. Bob receives the ciphertext and uses his private key to recover the note. Direct RSA encryption has message-size limits; larger files use a hybrid design.

Key Exchange and the Hybrid Approach

Figure 6.3 applies both methods to a large report. In this example of envelope encryption, Alice encrypts the report with a fresh symmetric content key and protects that key with Bob's authenticated public key.

Figure 6.3: A hybrid file-encryption example. Symmetric encryption handles the report; public-key encryption protects its small content key. This example uses RSA key transport.

Text description for Figure 6.3

Alice creates a fresh random content key K. Step 1 uses AES-GCM to encrypt the report. Step 2 uses RSA-OAEP and Bob's verified public key to encrypt K. Alice sends the encrypted key, file ciphertext, nonce, and authentication tag. In step 3 Bob's private key recovers K. In step 4 K decrypts and verifies the report. The two transmitted ciphertexts serve different purposes. Neither plaintext K nor Bob's private key travels across the network.

The Transport Layer Security (TLS) handshake also combines public-key mechanisms with symmetric encryption. A common certificate-authenticated TLS 1.3 connection uses ephemeral key agreement, in which temporary private values remain at the endpoints:

The client and server negotiate supported parameters and exchange public key shares.
The server provides its certificate and a handshake signature; the client validates the server's identity.
Both endpoints compute a shared secret and derive traffic keys locally.
Symmetric authenticated encryption protects application traffic, with separate keys for each direction.

This is a conceptual summary. TLS 1.3 protects parts of the handshake as well, and its full exchange includes additional messages. Its public-key key-agreement flow does not send an RSA-encrypted session key. RFC 8446.

Analyst Perspective

When evaluating a protocol that claims to use "encryption," always ask: Which encryption is being used for what? TLS uses public-key mechanisms and symmetric encryption for different purposes. Understanding this distinction helps you identify misconfigurations, such as TLS sessions that negotiate weak symmetric ciphers.

Compare the file-transfer design with Figure 6.4. The figure shows a common certificate-authenticated TLS 1.3 connection using ephemeral key agreement, with temporary private values retained locally at each endpoint.

Figure 6.4: A conceptual TLS 1.3 connection. Public-key operations authenticate the service and establish a shared secret; key derivation produces symmetric traffic keys. Message ordering and encrypted handshake records are simplified.

Text description for Figure 6.4

The endpoints exchange ephemeral public shares and retain their private values. The service provides a certificate and signs the handshake. Alice's browser validates its identity. Both endpoints derive matching sets of traffic keys from the agreed secret and handshake context. Different keys protect the request and response directions. The diagram omits Finished messages, other handshake details, and resumption. Application traffic uses authenticated symmetric encryption.

6.2 Encryption Levels

Encryption protects data in different states. The classification depends on where the data is and what risk it faces.

Data-at-Rest

Data-at-rest is data stored on disk, in databases, or in cloud storage. It is not currently being transmitted or processed.

Full-Disk Encryption (FDE) encrypts the entire storage device, including the operating system, applications, and data. Tools like BitLocker (Windows) and FileVault (macOS) are FDE solutions. If a laptop with FDE is stolen, an attacker cannot read the disk without the encryption key. FDE is fast because modern processors include hardware acceleration for AES (AES-NI), making encryption and decryption nearly transparent to the user. However, FDE protects the disk; it does not protect data in memory. Once a system is booted and unlocked, sensitive data in RAM may be accessible through memory attacks or if an attacker gains live access.

Partition-level and file-level encryption offer more granular control. A file manager can encrypt specific folders or files while leaving the rest of the system unencrypted. This approach allows different parts of the system to have different protection levels, but it requires users to actively manage which folders are encrypted, making mistakes more likely.

Database encryption protects data within database management systems. Transparent Data Encryption (TDE) in SQL Server or similar features in other databases encrypt data at the storage layer; the database engine handles encryption and decryption transparently. Some databases also support column-level encryption, where sensitive columns (such as Social Security numbers or credit card numbers) are encrypted while others remain plaintext. This approach allows queries to operate on encrypted data without decrypting the entire database.

Data-in-Transit

Data-in-transit is data actively being transmitted across a network.

Transport Layer Security (TLS) is the cryptographic protocol underlying HTTPS. It provides confidentiality, authentication, and integrity. TLS 1.3 uses authenticated encryption for protected records; certificate-based handshakes use certificates and signatures to authenticate the server. TLS 1.3, released in 2018, removed support for older, weaker algorithms and significantly improved security and performance.

Virtual Private Networks (VPNs) create encrypted tunnels between a client and a server (or between networks). A VPN encrypts all traffic flowing through it, regardless of what application generates the traffic. This provides a blanket protection layer but does not protect data after it exits the VPN tunnel.

End-to-end encryption means only the intended recipient can decrypt the data; even the service provider cannot. Signal, for example, uses end-to-end encryption for messaging. WhatsApp uses the same Signal protocol. End-to-end encryption is strong from a confidentiality perspective but complicates compliance and content moderation.

Figure 6.5 follows a file across storage, a connection, and application processing.

Figure 6.5: Encryption boundaries depend on the data's state. The application may hold plaintext after decrypting stored or received data.

Text description for Figure 6.5

The left panel places encrypted data on storage and identifies a storage key. The middle panel places encrypted traffic between two connection endpoints, using connection keys. The right panel shows the receiving application processing plaintext in memory. Storage and transport encryption cover different boundaries. Their presence does not establish that data remains encrypted while an ordinary application uses it.

Algorithms and Key Length

The security of an encryption system depends on the strength of the algorithm and the size of the key. A weak algorithm can be broken even with a long key. A strong algorithm with a short key may be vulnerable to brute-force attacks.

Cryptographic Strength is measured in bits of security. A 128-bit key does not mean 128 bits of security; it depends on the algorithm and attack methods. For AES, a 128-bit key provides 128 bits of security. For RSA, a 2048-bit key provides only about 112 bits of security against the best-known attacks.

Organizations must balance security (longer keys are more secure) against performance (longer keys take longer to compute). NIST provides recommendations for key sizes based on the timeline:

Timeline	AES Key Length	RSA Key Length
Through 2030	128 bits	2048 bits
Through 2050	192 bits	3072 bits
2050+	256 bits	4096 bits

Post-quantum cryptography is an emerging concern. Quantum computers, if developed, could break RSA and ECC by solving certain mathematical problems exponentially faster than classical computers. NIST is standardizing quantum-resistant algorithms, but the transition is still years away.

6.3 Hashing, Salting, and Digital Signatures

Hashing is a one-way function. It takes data of any size as input and produces a fixed-size output called a hash or digest. The same input always produces the same hash. But a hash cannot be reversed: given a hash, you cannot recover the original data.

Cryptographic Hash Functions

A cryptographic hash function must be deterministic (same input = same output), fast to compute, avalanche-sensitive (a tiny change in input produces a completely different hash), and collision-resistant (it should be computationally infeasible to find two different inputs with the same hash).

SHA-256 (Secure Hash Algorithm 256-bit) produces a 256-bit hash. It is widely used for file integrity verification, digital signatures, and blockchain. Password storage requires a suitable salted password-hashing scheme with a configured work cost; a single SHA-256 pass is too fast for this purpose. SHA-256 is secure and widely trusted.

SHA-3, finalized by NIST in 2015, is the newest cryptographic hash standard. It is designed to be resistant to potential future attacks that might affect SHA-256, though no such attacks are currently known. SHA-3 is not yet as widely adopted as SHA-256 but is becoming more common.

Older algorithms like MD5 and SHA-1 are cryptographically broken. MD5 collisions can be generated easily; SHA-1 collisions have been demonstrated. Neither should be used for security purposes, though you will encounter them in legacy systems.

Forensic Applications of Hashing

In digital forensics, hashing supports checks that evidence bytes remain unchanged. When an investigator acquires a disk image, they compute its cryptographic hash and retain the digest in the case record. Later, they recompute the hash over the same bytes with the same algorithm and compare it with that trusted baseline. A match supports byte integrity. A mismatch requires investigation into acquisition, transfer, handling, and the selected byte range. Hashes complement provenance and chain-of-custody records.

This is why hash verification is a standard practice in incident response and forensics: it provides mathematical assurance of data integrity.

Figure 6.6 separates the trusted baseline from the copy being checked.

Figure 6.6: Hash comparison supports verification of byte integrity. A mismatch calls for investigation into the selected data, acquisition process, and handling history.

Text description for Figure 6.6

At acquisition, the examiner hashes the evidence image and retains the digest in a trusted case record. At examination, the examiner hashes the copy and compares the complete digests using the same algorithm and byte range. A match supports the conclusion that the compared bytes are unchanged. A mismatch requires investigation. Hash comparison alone does not establish provenance, document every custody event, or determine admissibility.

Salting and Password Security

Passwords are hashed before being stored in a database. When a user logs in, the system hashes their input password and compares it to the stored hash. If the hashes match, the password is correct.

Without additional protections, password hashing is vulnerable to dictionary attacks and rainbow tables. A rainbow table is a precomputed lookup table of hashes for common passwords. An attacker who steals a password database can compare each hash to the rainbow table and quickly recover many passwords.

A salt is a random value supplied to a password-hashing scheme along with the password. Each account receives its own salt, so identical passwords produce different stored hashes when their salts differ. The system stores the salt and the scheme's work settings with the hash. An attacker can still test password guesses, but must do the computation separately for each salt. NIST password-verifier guidance.

Modern password hashing algorithms like bcrypt, scrypt, and Argon2 include salting and are intentionally slow. Computing a bcrypt hash takes hundreds of milliseconds, making brute-force attacks expensive. A user logging in waits a fraction of a second; an attacker trying to crack a password by guessing millions of possibilities faces an enormous computational cost.

Compare the two account records in Figure 6.7.

Figure 6.7: Separate salts make identical passwords produce different verification records. A suitable password-hashing scheme also applies a configured work cost.

Text description for Figure 6.7

Account A uses salt A, and account B uses salt B. Both rows pass the password and salt through a password-hashing scheme with a configured work cost. Each record stores the resulting hash and salt; a real record also retains the algorithm and work settings needed for verification. Salts may be public. They prevent reuse of one precomputed result across all accounts, while an attacker can still test guesses separately.

Digital Signatures

A digital signature binds a message to a signing key and allows a recipient to check its integrity. Identity attribution also depends on validating the public key's owner and protecting the private key.

To create a digital signature, the sender:

Supplies the message and private signing key to a signature algorithm.
Generates the signature using that algorithm's defined processing, which commonly includes hashing.
Sends the message and signature to the recipient.

The recipient:

Obtains an authenticated copy of the sender's public verification key.
Supplies the received message, signature, and public key to the verification algorithm.
Receives a valid or invalid result.

Signing and verification are distinct cryptographic operations. A valid result supports message integrity and attribution to the signing key. Signing alone does not conceal the message. NIST Digital Signature Standard.

Signature Validity Does Not Mean Trustworthiness

A valid digital signature supports attribution to the corresponding signing key; key compromise can undermine that attribution. It does not prove that person is trustworthy or that the message's claims are true. A malicious actor can sign their own messages. You still need to verify that you trust the sender before acting on their message.

Follow the signing key and verification key in Figure 6.8.

Figure 6.8: Alice signs with her private key, and Bob verifies with Alice's authenticated public key. Signing alone leaves the message readable.

Text description for Figure 6.8

Alice supplies the message and her private signing key to a signature algorithm. She sends the original message with the resulting signature. Bob obtains an authenticated copy of Alice's public verification key. Verification uses that key, the received message, and signature to return valid or invalid. A valid result supports integrity and attribution to the signing key; trust also depends on key custody and the identity binding.

6.4 Public Key Infrastructure

Public Key Infrastructure (PKI) is the organizational framework that manages digital certificates and the keys they contain. It answers the question: How do you know that a public key actually belongs to the person or entity you think it does?

The Problem of Identity

When you visit a website over HTTPS, your browser receives the server's public certificate. Inside that certificate is a public key. You need that key to establish the encrypted connection. But how do you know the certificate actually belongs to the legitimate website and not to an attacker?

Without PKI, you would have to somehow verify the certificate through an out-of-band channel or meet the website operator in person. Neither is practical for internet-scale communication. PKI solves this by introducing trusted third parties called Certification Authorities (CAs).

Certificate Authorities and the Root of Trust

A Certification Authority (CA) is an organization that issues digital certificates. Before issuing a certificate, the CA verifies the applicant's identity and ownership of a domain (for website certificates) or role in an organization (for internal certificates). The CA then signs the certificate using its own private key.

Your browser or operating system has a configured set of trusted root certificates. The client validates the service certificate through a chain of issuer signatures to one of these trust anchors. It also checks the expected service name, validity period, certificate constraints and permitted use, and applicable revocation policy. A valid signature alone is insufficient to accept the service certificate. Certificate path validation and TLS service identity.

The CA is the root of trust. If a CA is compromised, an attacker could issue fraudulent certificates for any website. For this reason, CAs invest heavily in security and are audited by independent firms.

Certificate Chain and Hierarchy

Large organizations often use a hierarchy of CAs. A root CA is kept offline and signs only intermediate certificates. Intermediate CAs are online and sign end-entity certificates (certificates for websites, users, or devices). If an intermediate CA is compromised, the damage is limited; the root CA can revoke and replace it. If the root CA is compromised, the entire trust structure collapses.

When a browser receives a website certificate, it may receive a chain of certificates:

The website's certificate (signed by an intermediate CA)
The intermediate CA's certificate (signed by a root CA)
(Optionally) other intermediate certificates

The browser verifies the chain by checking each signature until it reaches a root certificate it trusts.

Figure 6.9 shows the issuing hierarchy alongside the client's validation checks.

Figure 6.9: A service certificate must validate through a configured trust anchor and satisfy the client's name, time, usage, and status requirements.

Text description for Figure 6.9

The client has a configured trust anchor. The root signs an intermediate CA certificate; the intermediate signs the service certificate. That certificate contains the service's public key and name, illustrated by the reserved name portal.example. The client validates the certification path and relevant constraints, checks the expected service name and validity period, and applies its revocation policy. A root's self-signature alone does not establish trust.

Certificate Types and Lifecycle

Domain Validation (DV) certificates verify ownership of a domain. The CA sends a verification code to the domain owner (via email or HTTP challenge), confirms receipt, and issues the certificate. DV certificates are issued quickly and cheaply. Any DV certificate is technically valid for HTTPS, though no identity information beyond domain name is verified.

Organization Validation (OV) certificates require verification of the organization's legal existence, registration, and physical address. They take longer to issue but signal a higher level of identity verification.

Extended Validation (EV) certificates require the most rigorous verification, including phone confirmation. Historically, EV certificates displayed a green bar in browsers, signaling "this is a trustworthy company." That visual indicator has been largely deprecated because users confused it with simple HTTPS; phishing sites can obtain DV certificates. EV certificates still exist and carry more verified identity information, but the browser no longer gives them special visual treatment.

Wildcard certificates can cover one matching domain-name label: for example, *.example.com can match mail.example.com, but does not by itself cover example.com or a.mail.example.com. Subject Alternative Name (SAN) certificates, also called multi-domain certificates, list multiple names in one certificate. TLS wildcard matching.

Certificate Revocation

Certificates have an expiration date. Renewal obtains a new certificate, usually before the current one expires. Issuing the replacement does not automatically revoke the old certificate; each certificate retains its own validity period and revocation status.

Sometimes a certificate must be revoked before expiration: the private key is compromised, the domain changes ownership, or the certificate was issued in error.

Certificate Revocation List (CRL) is a list of revoked certificates published by the CA. Browsers can download the CRL and check if a certificate is listed. However, CRLs can be large and are refreshed periodically, creating a window of time when a revoked certificate might still be trusted if the browser has not yet downloaded the latest CRL.

Online Certificate Status Protocol (OCSP) lets a client request a signed status response for a certificate. The response can report good, revoked, or unknown. Clients may cache responses, use stapled responses, or rely on other status mechanisms according to their policy. A good response does not replace the remaining certificate-validation checks. RFC 6960.

OCSP Stapling is a compromise: the website operator queries OCSP periodically and includes the signed response in the TLS handshake, eliminating the need for the browser to contact the OCSP server.

Figure 6.10 separates routine certificate expiration from an incident that requires early revocation.

Figure 6.10: Issuance, deployment, expiration, and revocation are separate lifecycle events. Renewal creates a new certificate; an incident involving a compromised key also requires replacing that key.

Text description for Figure 6.10

The owner generates a key pair and protects the private key. The issuer validates a request and issues a signed certificate for deployment. Before expiration, the owner can obtain and deploy a new certificate. If the private key is compromised, the certificate must be revoked and its status published through the applicable mechanism. Replacing the compromised key and certificate is a separate recovery action. Clients enforce status according to their validation policy.

Putting It Together: PKI in Practice

A company needs an internal certificate authority to issue certificates for its internal websites and services. The company generates a root CA key (kept in an offline secure facility), uses it to sign an intermediate CA certificate, and deploys the intermediate CA online. The intermediate CA then issues certificates for mail servers, internal wikis, VPN endpoints, and code signing.

Employees' browsers are configured to trust the company's root certificate. When they visit an internal website, they receive a certificate signed by the intermediate CA, verify it against the root, and establish a secure connection without warnings.

If the intermediate CA is compromised, the organization revokes it, generates a new one, and reissues certificates to all services.

6.5 Obfuscation and Tools

Obfuscation in Security

Obfuscation makes data or code harder to understand but does not provide cryptographic security. Code obfuscation transforms source code to make it difficult to reverse-engineer, using techniques like renaming variables to meaningless names, removing comments, and reordering logic. It is useful against casual analysis but not against a skilled adversary with sufficient time.

Data obfuscation or masking replaces sensitive values with fictional but realistic-looking values. A developer testing a payment system might use obfuscated credit card numbers: real structure, but fake accounts. This prevents accidental exposure of real customer data.

Obfuscation is a defense-in-depth layer, not a primary security control. Never rely on it alone.

Compare the three transformations in Figure 6.11.

Figure 6.11: Encoding changes representation, encryption protects confidentiality through keys, and variable renaming obscures the readability of code.

Text description for Figure 6.11

The encoding row converts the five ASCII characters Hello, with no newline, to SGVsbG8= using Base64. Anyone can apply the public decoding rule. The encryption row uses a secret key to protect Hello as ciphertext. The obfuscation row changes total = price * count into a = b * c by renaming the corresponding variables consistently. The operation remains multiplication, although the names convey less meaning.

Cryptographic Tools and Implementation

Organizations use cryptographic libraries and tools to implement encryption, hashing, and digital signatures without developing custom cryptographic algorithms (which is extremely risky).

OpenSSL is an open-source library and toolkit widely used on Linux, macOS, and other Unix-like systems. It provides command-line tools for generating keys, creating certificates, and testing encryption. System administrators use OpenSSL to diagnose TLS problems.

GnuPG (GNU Privacy Guard) implements the OpenPGP standard for encrypting files and email. It uses a "web of trust" model: you trust a key because you have verified it in person or because you trust other people who have verified it.

Cryptographic modules are validated against standards like FIPS 140-2 (or the newer FIPS 140-3) to ensure they implement algorithms correctly. Organizations handling sensitive data often require FIPS-validated modules.

Analyst Perspective

When selecting a cryptographic library or tool, check its maturity, adoption, and security track record. Avoid custom cryptographic implementations. Trust well-established libraries (OpenSSL, Bouncy Castle, libsodium) over academic or boutique alternatives, and keep them updated.

Chapter Summary

Encryption protects confidentiality by transforming plaintext into ciphertext using a key. Encoding is not encryption; obfuscation is not cryptographically secure.
Symmetric encryption uses a shared secret key and is fast and efficient. AES-256 is the modern standard. The key distribution challenge is solved by asymmetric encryption, which uses a public key (known to all) and a private key (secret).
RSA and ECC are the dominant asymmetric algorithms. ECC achieves equivalent security with smaller key sizes.
Hybrid designs combine public-key mechanisms for key establishment or key protection with symmetric encryption for bulk data. Certificate-authenticated TLS 1.3 commonly uses ephemeral key agreement.
Data-at-rest is protected by full-disk encryption, partition-level encryption, file-level encryption, or database encryption. Data-in-transit is protected by TLS, VPNs, or end-to-end encryption.
Hashing is a one-way function that produces a fixed-size digest. Cryptographic hash functions like SHA-256 are collision-resistant. Salting a password before hashing defeats rainbow table attacks. Bcrypt, scrypt, and Argon2 intentionally slow down hashing to make brute-force attacks impractical.
Digital signatures use private-key signing and public-key verification to support integrity and attribution to a signing key. Identity assurance also depends on the public-key binding and private-key protection.
Public Key Infrastructure (PKI) manages digital certificates and establishes a chain of trust through Certification Authorities (CAs), root certificates, and certificate chains.
Certificate revocation is handled through CRLs or OCSP. Certificates expire and must be renewed.
Obfuscation is not cryptographic security; it is a defense-in-depth layer useful against casual analysis.