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.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

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. The National Institute of Standards and Technology (NIST) defines a cryptographic algorithm as "a well-defined computational procedure that takes variable inputs, including a cryptographic key, and produces an output." This definition anchors cryptography within information security as a technical control, distinct from policy, physical, or administrative controls.

The operational scope of cryptography in infosec spans five functional domains: data confidentiality (encryption), data integrity (hashing and message authentication), authentication (digital signatures and certificate-based identity), non-repudiation (signed audit trails), and key establishment (key exchange protocols). Regulatory instruments including FIPS 140-3 — the federal standard for cryptographic module validation — and NIST SP 800-175B Rev. 1 establish the boundaries of approved cryptographic use for US government systems and contractors.

The cybersecurity frameworks and standards landscape treats cryptography as a foundational control category, appearing in NIST SP 800-53 Rev. 5 under the SC (System and Communications Protection) family, which contains 51 controls addressing encryption, key management, and cryptographic protection requirements for federal information systems.

Core mechanics or structure

Symmetric-key cryptography

Symmetric algorithms use a single shared key for both encryption and decryption. The Advanced Encryption Standard (AES), standardized in FIPS 197 by NIST in 2001, operates on 128-bit blocks with key sizes of 128, 192, or 256 bits. AES operates through a substitution-permutation network across 10, 12, or 14 rounds respectively. The core security assumption rests on key secrecy and computational hardness of exhaustive search — a 256-bit AES key requires approximately 2²⁵⁶ operations to brute-force under current classical computing models.

Block cipher modes of operation — CBC (Cipher Block Chaining), GCM (Galois/Counter Mode), CTR (Counter Mode) — determine how a block cipher processes data streams. GCM is an authenticated encryption mode that simultaneously provides confidentiality and integrity, making it the preferred mode for TLS 1.3.

Asymmetric (public-key) cryptography

Asymmetric systems use mathematically linked key pairs: a public key for encryption or signature verification, and a private key for decryption or signing. RSA (Rivest–Shamir–Adleman), defined in IETF RFC 8017, derives security from the computational difficulty of factoring large integers. NIST SP 800-131A Rev. 2 disallows RSA key sizes below 2048 bits for government use.

Elliptic Curve Cryptography (ECC) achieves equivalent security to RSA at smaller key sizes — a 256-bit ECC key is considered equivalent to a 3072-bit RSA key under NIST SP 800-57 Part 1 Rev. 5. This makes ECC the standard for constrained environments, mobile platforms, and modern TLS implementations.

Cryptographic hashing

Hash functions produce a fixed-length digest from arbitrary-length input. SHA-256, part of the SHA-2 family standardized in FIPS 180-4, produces a 256-bit digest. SHA-3 (Keccak), standardized in FIPS 202, provides an alternative construction using a sponge function and is the mandatory fallback if SHA-2 vulnerabilities are discovered.

The public key infrastructure ecosystem depends on hash functions for certificate fingerprinting, certificate chain validation, and digital signature binding.

Causal relationships or drivers

Regulatory mandate

FIPS 140-3 validation is mandatory for cryptographic modules used in federal civilian agencies and their contractors under OMB Circular A-130. The CMMC compliance framework requires Defense Industrial Base contractors to implement FIPS-validated cryptography for Controlled Unclassified Information (CUI) under CMMC Level 2 and above — a requirement drawn directly from NIST SP 800-171 Rev. 2, control 3.13.10.

HIPAA cybersecurity requirements, enforced by HHS Office for Civil Rights, do not mandate specific algorithms but treat encryption of electronic Protected Health Information (ePHI) as an addressable specification under 45 CFR §164.312(e)(2)(ii), where risk analysis determines implementation necessity.

Computational threat evolution

The emergence of quantum computing threatens the security assumptions underlying RSA and ECC. NIST initiated a post-quantum cryptography (PQC) standardization process and in 2024 published the first three finalized PQC standards: FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber), FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, formerly SPHINCS+). The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) establishes a migration timeline with a target completion year of 2030 for National Security Systems.

Classification boundaries

Cryptographic systems are classified along four primary axes:

By key architecture: Symmetric (single shared key), asymmetric (public/private key pair), or hybrid (asymmetric key exchange + symmetric bulk encryption — the model used by TLS).

By function: Encryption (confidentiality), hashing (integrity), MAC (message authentication code, integrity + authenticity), digital signature (non-repudiation + authenticity), key derivation (KDF), and key agreement (e.g., Diffie-Hellman).

By validation status: FIPS 140-3 defines four security levels (Levels 1–4), with Level 1 covering basic algorithmic correctness and Level 4 requiring physical tamper resistance. The NIST Cryptographic Module Validation Program (CMVP) maintains the authoritative list of validated modules.

By export control classification: The US Export Administration Regulations (EAR), administered by the Bureau of Industry and Security (BIS) under 15 CFR Part 742.15, impose license requirements on cryptographic items exceeding specific key-length thresholds when exported to controlled destinations.

Tradeoffs and tensions

Performance vs. security level: AES-256 processes data slower than AES-128 on software implementations. For hardware-accelerated environments using AES-NI instructions (available on Intel processors since the Westmere generation, 2010), the throughput differential is negligible. On embedded systems without hardware acceleration, the 40% additional round operations in AES-256 versus AES-128 represent a measurable latency cost.

Key size vs. forward secrecy: Long-lived RSA keys simplify certificate management but create retrospective decryption risk if the private key is later compromised. Ephemeral key exchange protocols (ECDHE — Elliptic Curve Diffie-Hellman Ephemeral) provide forward secrecy by generating session-unique key material, but require computational overhead per session. TLS 1.3 mandates forward secrecy by eliminating non-ephemeral cipher suites.

Cryptographic agility vs. implementation complexity: Designing systems to support algorithm replacement (cryptographic agility) is a NIST-recommended practice per SP 800-131A Rev. 2, but maintaining multiple algorithm paths increases code surface area and testing burden, as documented in the CISA post-quantum migration guidance.

Regulatory compliance vs. operational context: FIPS-approved algorithms may restrict options available in high-throughput or resource-constrained applications. ChaCha20-Poly1305, widely deployed in mobile TLS due to performance advantages on platforms lacking AES hardware acceleration, was added to IETF RFC 7905 for TLS but carries conditional FIPS status under specific validated module implementations.

The intersection of cryptography with identity and access management introduces additional tension: certificate-based authentication requires PKI infrastructure that must be independently maintained, audited, and revoked on schedule — creating operational burden that organizations sometimes resolve by downgrading to weaker password-based schemes.

Common misconceptions

Misconception: Encryption alone ensures data security.
Encryption protects confidentiality but does not prevent data deletion, unauthorized access by key holders, or integrity violations if no MAC or AEAD scheme is applied. An attacker with the key — or with access to a decryption oracle — can access plaintext regardless of cipher strength. NIST SP 800-111 addresses this specifically in the context of storage encryption.

Misconception: SHA-256 is an encryption algorithm.
SHA-256 is a one-way hash function, not an encryption algorithm. It has no associated key and produces an irreversible digest. Confusing hashing with encryption is one of the most common implementation errors documented in application security audits, as noted in OWASP's Cryptographic Failures category — ranked second in the OWASP Top 10 2021.

Misconception: HTTPS means the server is trustworthy.
HTTPS confirms that the transport channel is encrypted and that the server certificate was signed by a trusted Certificate Authority. It does not validate the server operator's identity, legitimacy, or the integrity of the content served. Phishing sites routinely obtain valid TLS certificates, as documented by APWG eCrime research.

Misconception: AES-128 is insecure.
AES-128 has no known practical attack faster than brute force. NIST continues to approve AES-128 for most applications under FIPS 197. The preference for AES-256 in high-security contexts is based on quantum threat modeling (Grover's algorithm halves effective key length to 128 bits for a quantum adversary), not any classical weakness in AES-128.

Checklist or steps (non-advisory)

The following sequence reflects the cryptographic implementation review phases documented in NIST SP 800-175B Rev. 1 and NIST SP 800-57 Part 2 Rev. 1:

1. Algorithm selection — Confirm algorithm is on the NIST-approved list for the applicable security category (per FIPS 140-3 and SP 800-131A Rev. 2). Disallowed algorithms include DES, 3DES for new applications, RC4, and MD5 for digital signatures.
2. Key length determination — Map required security strength (80-bit, 112-bit, 128-bit, 192-bit, 256-bit) to algorithm and key size using SP 800-57 Part 1 Rev. 5 Table 2.
3. Mode of operation selection — Select block cipher mode appropriate to use case: GCM for authenticated encryption, CTR for streaming, CBC only with HMAC (Encrypt-then-MAC pattern) for legacy compatibility.
4. Key generation — Use a FIPS 140-3 validated cryptographically secure random number generator (CSRNG). SP 800-90A Rev. 1 defines approved Deterministic Random Bit Generator (DRBG) constructions.
5. Key storage and protection — Document key storage location, access controls, and hardware security module (HSM) usage where Level 3 or Level 4 FIPS requirements apply.
6. Key lifecycle management — Define cryptoperiod (maximum active lifetime) per SP 800-57 Part 1 Rev. 5 Table 1, covering activation, deactivation, and destruction phases.
7. Certificate management (if applicable) — Establish CA hierarchy, certificate validity periods, revocation mechanism (CRL or OCSP), and automated renewal procedures.
8. Post-quantum readiness assessment — Inventory all cryptographic deployments and flag RSA, ECDH, and ECDSA uses for PQC migration planning per CISA PQC guidance and NSA CNSA 2.0 timeline.
9. Module validation verification — Confirm any cryptographic library or hardware module used in federal or regulated contexts appears on the CMVP validated modules list.
10. Logging and audit — Confirm cryptographic operations are logged with sufficient detail to support forensic review, per SP 800-53 Rev. 5 control AU-10 (Non-repudiation).

Reference table or matrix