Encryption is the process of converting readable data (plaintext) into an unreadable format (ciphertext) using a mathematical algorithm and a key, so that only someone holding the correct key can reverse the process and read the original data. It underpins nearly every security control that matters in modern software: TLS 1.3 protects data moving between a browser and a server, AES-256 protects data sitting in a database or S3 bucket, and RSA-2048 or ECDSA signatures verify that a software package or container image hasn't been tampered with. Encryption is not optional infrastructure — it's the load-bearing wall of confidentiality and integrity. When it's implemented with outdated algorithms, hardcoded keys, or missing key rotation, attackers don't need to break the math; they just walk around it. This glossary entry covers what encryption actually does, how the major algorithm families differ, where it breaks down in real codebases, and what compliance frameworks require.
What is encryption, technically?
Encryption is a reversible transformation of data using an algorithm (a cipher) and a secret input (a key), producing ciphertext that is computationally infeasible to reverse without that key. The strength of an encryption scheme is measured by key length and algorithm design, not obscurity — this is Kerckhoffs's principle, formalized in 1883, which states a cryptosystem should remain secure even if everything about it except the key is public knowledge. Modern implementations follow this: AES (Advanced Encryption Standard) was standardized by NIST in FIPS 197 in November 2001 after a five-year open competition, and its full specification is public. A 128-bit AES key has roughly 3.4 x 10^38 possible values; brute-forcing it at a billion billion attempts per second would still take longer than the current age of the universe. Security comes from key secrecy and correct implementation, not from hiding the algorithm.
How does symmetric encryption differ from asymmetric encryption?
Symmetric encryption uses one shared key for both encrypting and decrypting data, while asymmetric encryption uses a mathematically linked key pair — a public key for encrypting or verifying, and a private key for decrypting or signing. AES-256 is the dominant symmetric algorithm today and is roughly 1,000x faster than RSA for bulk data, which is why it's used to encrypt the actual payload in a TLS session. RSA and elliptic-curve algorithms like ECDSA (commonly using the P-256 or Curve25519 curves) are asymmetric and are used where two parties haven't already shared a secret — for example, to negotiate a session key during a TLS handshake or to sign a container image digest so a registry can verify it wasn't altered. NIST's SP 800-57 recommends a minimum RSA key size of 2048 bits for any protection needed through 2030, and 3072 bits for protection beyond that, because factoring a 1024-bit RSA key is now considered within reach of well-resourced attackers.
What encryption algorithms are actually broken or deprecated?
DES, RC4, MD5, and SHA-1 are all cryptographically broken or deprecated and should not appear in any 2026 codebase, yet they routinely turn up in dependency trees. DES, adopted as a federal standard in 1977 with a 56-bit key, was formally withdrawn by NIST in 2005 after being broken in under 24 hours by the EFF's "Deep Crack" machine back in 1998. RC4, used for years in WEP and early TLS, was banned outright in TLS by RFC 7465 in February 2015 after multiple practical bias-based attacks. SHA-1, still found in legacy Git commit hashing and some certificate chains, was demonstrated broken with the "SHAttered" collision attack published by Google and CWI Amsterdam in February 2017, and browsers stopped trusting SHA-1 certificates by 2017. None of this is theoretical: CVE-2014-0160 (Heartbleed) wasn't a break of AES or RSA math — it was an OpenSSL memory-handling bug that leaked private keys directly out of server memory, proving that implementation flaws are usually a bigger risk than algorithm weakness.
Why does encryption fail even when the algorithm is strong?
Encryption fails in practice because of key management mistakes, not because AES-256 gets cracked — hardcoded keys, missing rotation, and weak random number generation account for the overwhelming majority of real-world breaks. Scanning open-source repositories consistently turns up AWS access keys, database connection strings, and TLS private keys committed directly into source, sometimes years before removal, remaining live in Git history indefinitely even after a later commit deletes them. The 2012 LinkedIn breach affected 6.5 million password hashes because they were stored as unsalted SHA-1, not because SHA-1 itself was the sole flaw — salting and a slower KDF like bcrypt or Argon2 would have made cracking far more expensive even with a weaker hash. Similarly, predictable random number generation was the root cause of the 2008 Debian OpenSSL vulnerability (CVE-2008-0166), which reduced the effective entropy of generated SSH and SSL keys to about 15 bits for two years, making every key generated on affected systems trivially guessable.
What compliance frameworks actually require encryption?
PCI DSS, HIPAA, GDPR, and FedRAMP all mandate encryption for sensitive data, but they specify outcomes rather than a single algorithm. PCI DSS 4.0, which became fully enforceable in March 2025, requires strong cryptography for cardholder data both at rest and in transit, and explicitly disallows SSL and early TLS. HIPAA's Security Rule (45 CFR 164.312) treats encryption as "addressable" rather than strictly required, but OCR enforcement actions routinely cite unencrypted PHI as the proximate cause of settlements, including a $2.3 million settlement in 2023 tied partly to unencrypted laptop data. FIPS 140-3, which replaced FIPS 140-2 for new module validations starting September 2021, is the standard federal agencies and their contractors must meet for cryptographic modules under FedRAMP. GDPR Article 32 lists encryption as an example of an "appropriate technical measure," and regulators have repeatedly pointed to its absence as an aggravating factor in fines following data exposure incidents.
How Safeguard Helps
Safeguard treats weak or misused encryption the same way it treats any exploitable software supply chain risk: by finding it and proving whether it matters. Our reachability analysis traces whether a flagged component — a deprecated cipher library, a package bundling MD5 or RC4, a TLS configuration allowing legacy protocol versions — is actually invoked in a code path attackers can reach, cutting through the noise of theoretical CVEs that never execute. Griffin AI reviews the surrounding code context to flag hardcoded keys, disabled certificate validation, and insecure randomness patterns that pure signature-based scanners miss. SBOM generation and ingest give teams a live inventory of every cryptographic library and its version across every repository, so a newly deprecated algorithm or a NIST withdrawal notice can be matched against your actual exposure in minutes. When a fix is available, Safeguard opens an auto-fix pull request that upgrades the dependency or corrects the configuration, so remediation ships as fast as the finding does.