Encryption and Cryptography Reference

Encryption and cryptography form the technical foundation of data confidentiality, integrity, and authentication across every layer of modern digital infrastructure. This page describes the service landscape, standards architecture, algorithm classifications, regulatory obligations, and operational tradeoffs that define professional cryptographic practice in the United States. The subject spans federal standards mandated by the National Institute of Standards and Technology (NIST), sector-specific compliance requirements enforced by agencies including HHS and the FTC, and an evolving threat environment driven by advances in quantum computing.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Cryptographic implementation reference checklist
• Reference table: algorithm and standard comparison matrix

Definition and scope

Cryptography is the mathematical discipline governing the transformation of information into forms that are unreadable without specific knowledge — a key, a protocol, or a secret — while preserving the ability of authorized parties to recover or verify the original data. Encryption is the applied subset of cryptography concerned specifically with confidentiality: converting plaintext to ciphertext using defined algorithms and key material.

NIST SP 800-175B Rev 1, Guideline for Using Cryptographic Standards in the Federal Government, defines the scope of cryptographic application across federal systems and establishes that encryption alone does not constitute a complete security posture — integrity verification and key management are co-equal requirements.

The operational scope of cryptography extends across five functional objectives:

• Confidentiality — preventing unauthorized disclosure of data in transit and at rest
• Integrity — detecting unauthorized modification of data
• Authentication — verifying the identity of communicating parties
• Non-repudiation — preventing denial of a transaction or communication
• Key establishment — securely generating and distributing cryptographic key material

The Digital Security Listings on this platform catalog service providers operating across each of these functional categories within the US market.

Regulatory scope is broad. The HIPAA Security Rule (45 CFR Part 164) addresses encryption of protected health information as an addressable implementation specification under §164.312(a)(2)(iv) and §164.312(e)(2)(ii). The FTC's Safeguards Rule (16 CFR Part 314) requires financial institutions to implement encryption of customer information in transit and at rest. The NIST Cybersecurity Framework (CSF) 2.0 positions cryptographic controls within the Protect function under the Data Security (PR.DS) category.

Core mechanics or structure

Cryptographic systems are built from three structural components: algorithms, keys, and protocols. Each has distinct properties and failure modes.

Algorithms define the mathematical transformation. The two primary families are symmetric and asymmetric. Symmetric algorithms — such as the Advanced Encryption Standard (AES), standardized in FIPS 197 — use the same key for encryption and decryption. AES supports key lengths of 128, 192, and 256 bits; NIST SP 800-131A Rev 2 designates AES-128 as the minimum acceptable for federal use. Asymmetric algorithms — including RSA and Elliptic Curve Cryptography (ECC) — use mathematically linked key pairs: a public key for encryption or signature verification and a private key for decryption or signing.

Keys determine the specific transformation within an algorithm. Key length directly correlates with resistance to brute-force attack. According to NIST SP 800-57 Part 1 Rev 5, an RSA key of 2048 bits provides roughly equivalent security strength to a 112-bit symmetric key, while a 256-bit ECC key corresponds to approximately 128-bit symmetric security.

Protocols orchestrate how algorithms and keys are applied across communication sessions. Transport Layer Security (TLS), currently at version 1.3 as defined in RFC 8446, combines asymmetric key exchange with symmetric session encryption. TLS 1.3 eliminates cipher suites considered cryptographically weak under prior versions, including RC4 and 3DES.

Hash functions occupy a distinct but essential structural role. SHA-256 and SHA-384, part of the SHA-2 family standardized in FIPS 180-4, produce fixed-length digests used in digital signatures, certificate validation, and message authentication codes (MACs). SHA-1 was formally deprecated by NIST for most applications in 2011 (NIST SP 800-131A).

Causal relationships or drivers

The demand for stronger cryptographic standards is driven by three compounding forces: computational power growth, mathematical advances, and regulatory escalation.

Moore's Law and brute-force feasibility: As processor performance increases, key lengths that were computationally prohibitive to attack in one decade become feasible in the next. This progression has driven successive deprecations — DES (56-bit key) was retired from federal use after demonstrated exhaustive-search attacks in the late 1990s, leading directly to the AES standardization process completed in 2001.

Quantum computing: Shor's algorithm, a quantum algorithm published in 1994 by mathematician Peter Shor, can factor large integers and solve discrete logarithm problems in polynomial time on a sufficiently powerful quantum computer. This would render RSA, ECC, and Diffie-Hellman key exchange cryptographically broken. NIST's post-quantum cryptography standardization process, initiated in 2016, produced its first four algorithm standards in 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FALCON (under review), all targeting resistance to quantum-enabled attacks (NIST Post-Quantum Cryptography).

Regulatory escalation: The Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) jointly published guidance in 2022 urging organizations to begin post-quantum migration planning immediately, citing a threat window of 10–15 years before cryptographically relevant quantum computers may emerge.

The Digital Security Authority's directory purpose and scope provides broader context for how cryptographic service providers are categorized within the US cybersecurity services landscape.

Classification boundaries

Cryptographic mechanisms are classified along four principal axes:

By key structure: Symmetric (single shared key) vs. asymmetric (public/private key pair) vs. hybrid (asymmetric key exchange bootstrapping symmetric session encryption).

By function: Encryption (confidentiality), hashing (integrity/fingerprinting), digital signatures (authentication + non-repudiation), key agreement/encapsulation (key establishment), and message authentication codes (integrity + authenticity without non-repudiation).

By implementation context: Software-based cryptographic libraries (e.g., OpenSSL, BoringSSL), hardware security modules (HSMs), Trusted Platform Modules (TPMs), and smartcard/token-based implementations. Federal systems handling classified information must use NSA-approved Type 1 encryption; unclassified federal systems must use FIPS 140-validated modules per FIPS 140-3, the current cryptographic module validation standard.

By validation status: NIST's Cryptographic Module Validation Program (CMVP) issues validation certificates to cryptographic modules tested by accredited laboratories. CMVP validation is mandatory for cryptographic modules used in federal systems per OMB Circular A-130.

Tradeoffs and tensions

Security strength vs. performance: Longer keys and computationally intensive algorithms reduce throughput. AES-256 imposes roughly 40% more computational overhead than AES-128 in software implementations without hardware acceleration (AES-NI). For high-throughput environments — network appliances processing multi-gigabit traffic — this tradeoff is operationally consequential.

Forward secrecy vs. key management complexity: Ephemeral key exchange protocols, such as Diffie-Hellman Ephemeral (DHE) and Elliptic Curve DHE (ECDHE), provide forward secrecy by generating a unique session key for each connection. This prevents retroactive decryption of captured traffic even if long-term private keys are later compromised. However, ephemeral sessions cannot be decrypted by passive network monitoring tools used for intrusion detection — a tension that enterprises deploying TLS inspection must explicitly address, often by deploying TLS interception proxies at network boundaries.

Standardization lag vs. threat evolution: NIST's formal standardization process, while authoritative, operates on multi-year timelines. The post-quantum algorithm selection process spanned 2016–2024. Organizations operating in high-assurance environments must weigh the risk of deploying non-standardized algorithms against the risk of waiting for formal approval while the threat environment evolves.

Encryption at rest vs. usability: Full-disk encryption protects data against physical theft but provides no protection against attacks on a running, authenticated system. File-level and application-layer encryption add granularity but introduce key management complexity. The HIPAA Security Rule's addressable (rather than required) designation for encryption reflects this tension — HHS acknowledges that implementation context determines feasibility (HHS Guidance on Encryption and Decryption).

Common misconceptions

Misconception: HTTPS means the entire site is secure.
HTTPS indicates that data in transit between client and server is encrypted using TLS. It provides no assurance about server-side storage encryption, application-layer access controls, or the trustworthiness of the server itself. A site can serve malware over a valid TLS connection.

Misconception: Encryption prevents data breaches.
Encryption reduces the impact of unauthorized data access but does not prevent breaches from occurring. If an attacker compromises an authenticated session or the decryption keys, encrypted data becomes accessible. The IBM Cost of a Data Breach Report 2023 — which documented an average breach cost of $4.45 million (IBM) — found that 19% of breaches originated from stolen or compromised credentials, a vector that bypasses encryption entirely.

Misconception: SHA-256 is an encryption algorithm.
SHA-256 is a cryptographic hash function, not an encryption algorithm. It produces a one-way fixed-length digest; the original input cannot be recovered from the hash. Encryption is reversible given the correct key; hashing is computationally irreversible by design.

Misconception: FIPS 140-2 and FIPS 140-3 validation is equivalent.
FIPS 140-3, effective September 2019, replaced FIPS 140-2 and introduced new requirements aligned with ISO/IEC 19790:2012. CMVP continued accepting FIPS 140-2 submissions until September 2021; certificates issued under FIPS 140-2 remain valid for five years from the date of issuance but do not satisfy procurement requirements specifying FIPS 140-3. Treating the two standards as interchangeable in procurement language is a documented compliance error (NIST CMVP Transition FAQ).

Misconception: End-to-end encryption means the service provider has no access.
End-to-end encryption (E2EE) architectures — where only the communicating endpoints hold decryption keys — vary in implementation. Some services described as E2EE retain key escrow mechanisms, backup access paths, or metadata that is not encrypted. Protocol specification review (not marketing claims) determines the actual access model.

Cryptographic implementation reference checklist

The following steps represent the structural phases of a cryptographic implementation lifecycle as documented in NIST guidance, particularly NIST SP 800-57 and NIST SP 800-175B. This is a reference sequence, not prescriptive professional advice.

1. Define protection objectives — identify data classification levels, applicable regulatory frameworks (HIPAA, PCI DSS, FISMA), and the specific cryptographic services required (confidentiality, integrity, authentication, non-repudiation).

2. Select approved algorithms — verify algorithm approval status against NIST SP 800-131A Rev 2; confirm key lengths meet current security strength requirements (minimum 128-bit equivalent symmetric security for most federal applications).

3. Select validated cryptographic modules — confirm FIPS 140-2 or FIPS 140-3 validation certificate status via the NIST CMVP for federal or regulated environments.

4. Establish key management procedures — document key generation, distribution, storage, rotation, revocation, and destruction procedures per NIST SP 800-57 Part 2 Rev 1.

5. Configure protocol versions and cipher suites — disable TLS 1.0 and TLS 1.1 (deprecated per NIST SP 800-52 Rev 2); enforce TLS 1.2 minimum or TLS 1.3 preferred.

6. Implement certificate lifecycle management — establish certificate authority (CA) trust anchors, certificate issuance procedures, renewal schedules, and revocation (CRL/OCSP) infrastructure.

7. Test cryptographic configurations — validate implementation against applicable test vectors; conduct independent assessment for high-assurance systems.

8. Document cryptographic inventory — maintain an up-to-date record of all cryptographic algorithms, key lengths, module versions, and expiration dates as a prerequisite for post-quantum migration planning (per NSA CNSS Policy 15).

9. Plan post-quantum migration — assess which cryptographic assets rely on RSA, ECC, or Diffie-Hellman; prioritize migration to NIST-standardized post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) per migration timelines published by CISA and NSA.

Reference table: algorithm and standard comparison matrix

The how-to-use-this-digital-security-resource page explains how this reference material maps to service provider listings.