Cryptography Fundamentals for InfoSec Practitioners

Cryptography underpins every layer of modern information security — from TLS handshakes protecting web traffic to the key management systems governing enterprise data-at-rest. This page maps the core mechanics, classification boundaries, regulatory obligations, and operational tradeoffs that define applied cryptography in professional infosec contexts. It serves practitioners, compliance analysts, and researchers who require a precise, reference-grade account of how cryptographic systems are structured and where they intersect with legal and standards frameworks. The infosec providers provider network provides entry points to service providers operating across these technical domains.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

Cryptography, as defined operationally within the US federal framework, is the discipline of transforming information to protect its confidentiality, integrity, and authenticity using mathematical algorithms and key material. NIST's Computer Security Resource Center glossary defines cryptography as "the discipline that embodies the principles, means, and methods for the transformation of data in order to hide their semantic content, prevent their unauthorized use, or prevent their undetected modification." Within the , cryptography occupies the role of a foundational primitive — the mechanism upon which access control, secure communications, digital signing, and data integrity verification are all built.

The operational scope of cryptography in professional infosec encompasses five distinct functional areas: confidentiality (encryption of data at rest and in transit), integrity verification (hash functions and message authentication codes), authentication (digital signatures and certificates), non-repudiation (audit-grade signing mechanisms), and key establishment (protocols for securely exchanging or deriving shared secrets). Federal scope is anchored by FIPS 140-3, the standard governing cryptographic module validation administered by NIST's Cryptographic Module Validation Program (CMVP). Any cryptographic module used in a US federal system must hold a valid FIPS 140-3 validation certificate unless a specific exemption applies.

Regulatory reach extends beyond federal procurement. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule, codified at 45 CFR §164.312(a)(2)(iv), designates encryption of electronic protected health information (ePHI) as an addressable implementation specification — meaning covered entities must implement it or document a risk-justified alternative. The Payment Card Industry Data Security Standard (PCI DSS), maintained by the PCI Security Standards Council, mandates strong cryptography for cardholder data transmission across open networks under Requirement 4.

Core mechanics or structure

The operational architecture of cryptography rests on three structural families: symmetric-key cryptography, asymmetric-key (public-key) cryptography, and hash functions.

Symmetric-key cryptography uses a single shared secret key for both encryption and decryption. The dominant standard is the Advanced Encryption Standard (AES), published as FIPS 197, which operates on 128-bit blocks with key sizes of 128, 192, or 256 bits. AES-256 is the configuration mandated by NSA's Commercial National Security Algorithm (CNSA) Suite for protecting data up to the TOP SECRET classification level, per NSA/CSS Policy Manual 1-52. Symmetric systems excel at bulk data encryption but require a secure out-of-band channel to exchange the shared key — the key distribution problem that public-key cryptography was designed to solve.

Asymmetric-key cryptography generates mathematically linked key pairs: a public key distributed openly, and a private key held exclusively by one party. RSA (Rivest–Shamir–Adleman) and Elliptic Curve Cryptography (ECC) are the dominant asymmetric systems in deployment. NIST recommends a minimum RSA key size of 2048 bits for current use, with 3072 bits providing security through 2030, per NIST SP 800-57 Part 1, Rev 5. ECC achieves equivalent security at significantly shorter key lengths — a 256-bit ECC key provides approximately the same strength as a 3072-bit RSA key — making it preferable in constrained environments.

Cryptographic hash functions accept arbitrary-length input and produce a fixed-length digest. SHA-256 and SHA-3 are the current NIST-approved hash algorithms under FIPS 180-4 and FIPS 202 respectively. Hash functions underpin digital signatures, certificate fingerprinting, password storage (when used with key-derivation functions such as PBKDF2, bcrypt, or Argon2), and blockchain-style integrity structures.

Key exchange protocols bridge the gap between symmetric efficiency and asymmetric key distribution. The Diffie-Hellman key exchange and its elliptic-curve variant (ECDH) allow two parties to derive a shared secret over an insecure channel without transmitting the secret itself. TLS 1.3, standardized in RFC 8446, mandates forward-secret key exchange using ECDHE or DHE, eliminating cipher suites that lack this property.

Causal relationships or drivers

Three primary forces shape cryptographic adoption and deprecation cycles in the professional infosec sector.

Computational advancement directly erodes the security margins of algorithms sized for prior threat models. The 56-bit Data Encryption Standard (DES) was formally withdrawn by NIST in 2005 after demonstrated exhaustive key-search attacks, and Triple-DES (3DES/TDEA) was disallowed for new applications as of 2023 per NIST SP 800-131A, Rev 2. SHA-1, once the dominant hash algorithm in TLS certificates, was deprecated following published collision attacks and is now prohibited in certificate issuance under CA/Browser Forum Baseline Requirements.

Quantum computing represents the projected long-term threat to current asymmetric systems. Shor's algorithm, when run on a cryptographically relevant quantum computer, can factor large integers in polynomial time — breaking RSA and discrete-logarithm-based ECC. NIST completed its post-quantum cryptography (PQC) standardization process with the publication of FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber), FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, formerly SPHINCS+) in 2024. Federal agencies are expected to begin migration planning under guidance from the Office of Management and Budget (OMB).

Regulatory mandates create adoption deadlines independent of voluntary best practices. FIPS 140-3 compliance is mandatory for federal agencies under OMB Circular A-130. The Cybersecurity Maturity Model Certification (CMMC) framework, administered by the Department of Defense, requires encryption controls aligned with NIST SP 800-171 for defense industrial base contractors handling Controlled Unclassified Information (CUI).

Classification boundaries

Cryptographic systems are classified along four independent axes, each relevant to different compliance and design decisions.

By key relationship: Symmetric (single shared key), asymmetric (public/private pair), and hybrid systems (asymmetric key exchange used to establish a symmetric session key, as in TLS).

By operational mode: Stream ciphers process data bit-by-bit or byte-by-byte (e.g., ChaCha20, used in TLS 1.3). Block ciphers operate on fixed-size data blocks and are used in modes that determine how multiple blocks are chained — modes include CBC, CTR, GCM, and CCM. AES-GCM is an authenticated encryption with associated data (AEAD) mode that provides both confidentiality and integrity in a single pass, per NIST SP 800-38D.

By security function: Encryption (confidentiality), message authentication codes/MACs (integrity and authenticity without non-repudiation), digital signatures (integrity, authenticity, and non-repudiation), and key derivation functions (KDFs).

By approval status: NIST maintains a three-tier classification — approved, deprecated (acceptable under specific conditions), and disallowed. The current status of all algorithms is published in NIST SP 800-131A, Rev 2. MD5 and SHA-1 are disallowed for digital signatures; 3DES is disallowed for new implementations; RSA-1024 is disallowed for all uses.

Tradeoffs and tensions

Security strength vs. performance: Larger key sizes and more computationally intensive algorithms improve security margins but increase processing overhead. AES-256 has a higher computational cost than AES-128, though hardware acceleration via AES-NI instructions on modern processors substantially narrows this gap. ECC's shorter keys make it the preferred choice for TLS handshakes on resource-constrained endpoints.

Forward secrecy vs. decryptability for lawful intercept: TLS 1.3's mandatory ephemeral key exchange means session keys are never stored, making retroactive decryption of captured traffic impossible even if the long-term server private key is later compromised. This property — perfect forward secrecy (PFS) — is a security strength but creates irreconcilable tension with enterprise network monitoring architectures and lawful intercept requirements that depend on passive decryption.

Post-quantum migration vs. operational stability: The PQC algorithms standardized by NIST in 2024 carry larger key and ciphertext sizes than their classical counterparts. ML-KEM-768 public keys are 1,184 bytes, compared to 294 bytes for a P-256 ECC public key — a size increase with measurable implications for protocols operating over bandwidth-constrained or latency-sensitive channels. Migration timelines for long-lived systems (industrial control, embedded infrastructure) are measured in years, not quarters.

Cryptographic agility vs. simplicity: Designing systems to swap algorithms without architectural changes (cryptographic agility) is a recommended practice per NIST IR 8413, but introduces implementation surface area and configuration complexity that itself becomes an attack vector if poorly managed.

Common misconceptions

Misconception: Encryption alone ensures data security. Encryption addresses confidentiality but provides no protection against deletion, unauthorized modification undetected by integrity controls, or insider access using legitimate credentials. A system can be fully encrypted at rest and still fail every other security objective in the CIA triad. Comprehensive security requires layered controls, as framed across the .

Misconception: HTTPS means a site is trustworthy. HTTPS indicates that transport-layer encryption is active between the client and server — it does not validate the server operator's identity beyond what the CA/Browser Forum certificate issuance process requires, and it provides no assurance about the security of the application or the integrity of the data being served.

Misconception: Longer keys always mean better security. Security derives from the hardness of the underlying mathematical problem relative to attacker resources. A 4096-bit RSA key does not provide twice the security of a 2048-bit RSA key in any linear sense — both rely on the same integer factorization problem, and sub-exponential attacks reduce the effective security increment substantially. Algorithm selection, mode of operation, and implementation quality are equally determinative.

Misconception: Deprecated algorithms are immediately dangerous. NIST's deprecation status means an algorithm should not be used for new applications and should be prioritized for migration, not that existing systems using it face imminent compromise. The distinction between deprecated and disallowed in SP 800-131A reflects this operational nuance.

Misconception: Open-source cryptographic libraries are inherently less secure than commercial products. NIST's FIPS 140-3 validation process applies equally to open-source and commercial modules. OpenSSL, for instance, holds multiple validated module certificates under the CMVP. Security is determined by implementation quality, audit history, and validation status — not by licensing model.

Checklist or steps

The following sequence reflects the phases of a cryptographic implementation review as structured in professional audit and compliance assessment contexts. The sequence is descriptive of the process, not prescriptive advice.

Phase 1 — Algorithm inventory
- Enumerate all cryptographic algorithms in use across systems, including those embedded in third-party libraries and firmware
- Identify key sizes, modes of operation, and protocol versions for each
- Map each algorithm against NIST SP 800-131A approval status (approved / deprecated / disallowed)

Phase 2 — Key management review
- Document key generation sources (hardware security modules, software RNGs, TPMs)
- Verify alignment with NIST SP 800-57 Part 1, Rev 5 key lifecycle phases: generation, distribution, storage, use, archival, revocation, destruction
- Confirm separation of duties for key custodianship

Phase 3 — Protocol and configuration audit
- Confirm TLS 1.0 and TLS 1.1 are disabled on all endpoints (both deprecated per RFC 8996)
- Verify TLS 1.3 or TLS 1.2 with forward-secret cipher suites is enforced
- Confirm cipher suite ordering prioritizes AEAD modes (e.g., AES-GCM, ChaCha20-Poly1305)

Phase 4 — Module validation check
- Verify that cryptographic modules used in federal or regulated contexts hold current FIPS 140-2 or FIPS 140-3 certificates via the CMVP vendor list
- Confirm no expired or historical certificates are relied upon as current coverage

Phase 5 — Post-quantum readiness assessment
- Identify systems with long-lived keys or data requiring confidentiality beyond a 10-year horizon
- Evaluate protocol support for hybrid classical/PQC key exchange (e.g., X25519+ML-KEM as specified in IETF drafts)
- Document planned migration timeline against OMB and CISA guidance thresholds

Phase 6 — Documentation and exception management
- Record all identified deviations with compensating control documentation
- Establish re-assessment intervals aligned with regulatory review cycles (typically annual for HIPAA, PCI DSS)

Reference table or matrix

Cryptographic Algorithm Comparison Matrix