Encryption Algorithms, and the Two Families They Fall Into

How it worksHow encryption algorithms work

An encryption algorithm is a mathematical method that turns readable information, called plaintext, into unreadable ciphertext, using a key. Decryption reverses the process with the right key. The algorithm itself is public. The security of the message rests entirely on keeping the key private.

That is a standard design principle in cryptography: a secure method stays secure even when an attacker knows exactly how it works. Secret, homemade encryption methods have a poor record, which is why cybersecurity guidance points to a published standard such as the Advanced Encryption Standard instead.

Different encryption algorithms protect information in two different states.

• Data at rest. Files, databases, backups and laptop disks. One party holds the key, so symmetric encryption does the whole job.
• Data in transit. A message, a web session or a VPN tunnel crossing a network. Two parties need a shared key, so the two families work together.

Encryption provides confidentiality. Most systems also need integrity, proof that a message was not altered, and authentication, proof of who sent it. Those come from hashes, message authentication codes and digital signatures, so encryption algorithms are almost always deployed inside a larger security protocol.

The familiesThe two families of encryption algorithms, and why every system uses both

Symmetric encryption uses one key for both encryption and decryption. Encrypting data with it is fast enough that a modern processor works at gigabytes per second, because AES has dedicated instructions in the silicon.

The problem is entirely logistical: both sides need the same key, and there is no safe way to send it over the same channel you are trying to protect.

Asymmetric encryption uses a mathematically linked pair, a public key and a private key. What one locks, only the other opens.

Publish the public key, keep the private key secure, and anybody can send you a message only you can decrypt, without ever having shared a secret. That solves the delivery problem, and it costs orders of magnitude more compute per byte.

So no serious protocol picks one. A TLS connection uses asymmetric encryption for a few kilobytes at the start, to authenticate the server and agree on a session key, and then uses symmetric encryption for all the data after that. IPsec does the same thing with a different handshake, and so does WireGuard, SSH and every messaging application worth using.

The symmetric vs asymmetric encryption question is therefore not a choice between two types of encryption. Understanding that split is what makes the rest of this legible. When somebody asks which of the encryption algorithms a system uses, the honest answer names two: one for the key exchange and one for the data.

SymmetricThe symmetric encryption shortlist

AES, the Advanced Encryption Standard, is the default symmetric encryption algorithm and has been since NIST published the standard in 2001. AES encryption protects information in TLS, disk encryption, Wi-Fi and most VPNs.

The number after AES is the key length, not the strength of the implementation: AES-128 has no practical weakness and AES-256 is chosen for margin and for compliance regimes that ask for it. Both are fine.

ChaCha20 matters for a specific reason. AES is fast because processors have instructions for it; where those instructions are missing, which used to mean phones and still means some embedded hardware, a software AES implementation is both slower and harder to write without timing leaks.

ChaCha20 is fast in plain software and constant time by construction, which is why mobile TLS often prefers it.

Blowfish and Twofish appear on most lists of types of encryption. Blowfish is a 1993 design by Bruce Schneier with a 64-bit block, so it shares the weakness that retired 3DES. Twofish, its 128-bit successor, was an AES finalist with no known practical break. It never became a standard, so almost nothing requires it.

The mode matters as much as the cipher. AES is a block cipher and a block cipher on its own only encrypts 16 bytes of data. The mode decides how blocks chain together, and the wrong choice has broken far more systems than the cipher ever has.

ECB mode leaks structure so visibly that the classic demonstration is an encrypted image where you can still see the picture. The modern answer is an authenticated mode, GCM for AES or Poly1305 for ChaCha20, which handles encryption and tamper detection in one pass.

AsymmetricThe asymmetric encryption shortlist

RSA is the public key algorithm everybody has heard of. RSA encryption rests its security on factoring being hard, and the cost of that is key size: 2048 bits is the floor for anything current and 3072 is the conservative choice. It is slow, the keys are large, and it survives because certificates and old systems were built around it.

Elliptic curve cryptography does the same jobs with dramatically smaller public and private keys, because the underlying problem is harder per bit. A 256-bit elliptic curve key is generally considered comparable to RSA at 3072 bits.

Smaller keys mean faster handshakes and less data on the wire, which is why TLS moved to it. P-256 is the NIST curve, and Curve25519 with its signature form Ed25519 is the modern favorite outside NIST-constrained environments.

Diffie-Hellman is the third thing in this family and it does not encrypt at all. It lets two parties derive a shared secret over a public channel, which is the key agreement step in most protocols.

The Diffie-Hellman exchange is worth understanding on its own, because it is the part that gives forward secrecy: a session key that was never transmitted cannot be recovered later from a stolen private key.

Signatures are the other half. RSA, ECDSA and Ed25519 produce signatures, and signing is how certificates prove who they belong to. Encryption gives you confidentiality for sensitive information. Digital signatures give you authenticity: the private key signs a message and anybody holding the public key can verify it. A secure protocol needs both.

RetiredWhat is retired, and why it matters that it lingers

DES used a 56-bit key and fell to brute force in the late 1990s. It is a museum piece.

3DES ran DES three times to compensate. It survived far longer than it should have, and its real weakness at the end was not key length but its 64-bit block size, which makes collisions practical once enough data passes under one key. It has been withdrawn and it is still found in payment terminals and old VPN appliances.

RC4 was a fast stream cipher with statistical biases in its output that turned into practical attacks. Browsers removed it.

The reason retirement matters operationally is that old encryption algorithms rarely fail loudly. A TLS server that still offers 3DES will happily negotiate it with any client that asks, and everything keeps working. Information that should have been secure is not.

Nothing appears in a log. The only way to know is to scan for what the server offers rather than what it prefers, which is the same discipline as patching: the absence of a symptom is not evidence.

Post-quantumPost-quantum, without the hype

A sufficiently large quantum computer would break RSA and elliptic curve cryptography, because Shor's algorithm solves both underlying problems efficiently. Symmetric encryption is affected much less: the practical advice for AES is that doubling the key size restores the security margin, which is one more reason AES-256 gets chosen for sensitive data.

This is no longer theoretical planning. On August 13, 2024, NIST published the first finalized post-quantum standards. FIPS 203 specifies ML-KEM, a module-lattice key encapsulation mechanism for establishing shared keys over a public channel, in three parameter sets. FIPS 204 and FIPS 205 were released alongside it and specify digital signature schemes, ML-DSA and SLH-DSA.

The deployment pattern that has emerged is hybrid: run a classical key exchange and a post-quantum one together and combine the results, so the session is safe if either survives. Browsers and cloud providers have been enabling this on TLS connections since 2024.

The threat model that justifies acting now is harvest now, decrypt later. Encrypted data captured today can be stored until a machine exists to decrypt it, so anything with a long confidentiality requirement is already exposed. Anything that stops mattering in two years is not.

PitfallsWhere implementations actually fail

Almost nothing in the list above is what breaks in practice. The failures are around the algorithm rather than in it.

Keys that live next to the data. A database whose encryption key sits on the same server in a config file is protected against theft of the disk and nothing else. Key management, meaning how keys are generated, stored, rotated and destroyed, is the part of encryption security organizations underinvest in.

Rolling your own. Not the algorithm, which nobody does any more, but the protocol around it: inventing a way to combine encryption with authentication, reusing a nonce, building a padding scheme. Every one of those has a standard answer and a long history of homemade versions failing.

Reusing a nonce or an initialization vector. With a stream cipher or with GCM, using the same nonce twice under the same key is catastrophic and silent. This is the single most common real cryptographic failure in application code.

Encryption without authentication. Confidentiality alone lets an attacker modify encrypted data undetected. Authenticated modes exist precisely so this is not a decision anyone has to make.

Certificates nobody tracks. An expired certificate is an outage, and a certificate with a key that was generated ten years ago at a size nobody would choose today is a slower problem. Both are inventory questions rather than cryptography questions.

Assuming compliance means secure. A configuration can satisfy an audit and still offer a retired cipher suite to any client that asks for it, which is not a secure configuration in any sense that matters.

ComparisonSymmetric, asymmetric and hashing, side by side

The last row is the one that determines the next few years of work. Symmetric encryption survives with larger keys. Asymmetric encryption has to be replaced, and the standards to replace it with now exist.

Hash functions sit outside both families because they do not encrypt anything, and confusing them with encryption is the most common conceptual mistake in this area.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Remote access WireGuard Explained A protocol that made the shortlist above its whole design, with no cipher negotiation to get wrong. Open this next14 min

• Cryptography · 11 min Hash Functions, and Why the Right One Depends on the Job The third thing people call encryption, which encrypts nothing: one way, no key, and it protects integrity rather than secrecy.
• Cryptography · 12 min Diffie-Hellman Key Exchange The key agreement step itself, and where forward secrecy comes from.
• Cryptography · 10 min The BitLocker Recovery Key, and Why the Screen Appeared What the key unlocks.
• Cryptography · 10 min Full Disk Encryption, and What It Does Not Protect Full disk encryption explained: what it protects, where it stops, and how to manage recovery keys.
• Security operations · 10 min Data Classification, and Why Every Label Needs a Rule Which data needs encryption at all: classification levels and the handling rules tied to them.
• Cryptography · 9 min FileVault Disk Encryption, and Why the Disk Is Already Encrypted A working example of AES-XTS protecting a volume in hardware.
• Wireless security · 11 min WPA2-PSK, and Why the Password Is the Whole Security Model The cipher underneath WPA2, strong regardless of how weak the passphrase is.
• Identity and access · 12 min CyberArk vs HashiCorp Vault Where keys and secrets are kept and handed out once the algorithm is chosen.
• Cloud security · 11 min KMS vs Secrets Manager, and Why Every Secret Already Uses KMS A worked case of AES-256 data keys wrapped by a key held in hardware.