Encryption Algorithms

Introduction to Encryption

Encryption is the process of converting plaintext into ciphertext to protect data confidentiality. Encryption algorithms are fundamental to modern cybersecurity, enabling secure communication, data protection, and privacy. Understanding encryption algorithms is crucial for anyone working with secure systems, cryptography, or data protection.

This chapter covers popular cryptographic algorithms, each serving different purposes:

• Symmetric Encryption: AES, DES — same key for encryption and decryption
• Asymmetric Encryption: RSA — different keys for encryption and decryption
• Hash Functions: SHA, MD5 — one-way functions for integrity and fingerprinting

A note on terminology: hash functions are not encryption. Encryption is reversible and takes a key; hashing is neither. They are grouped here because they are cryptographic primitives you will use together, not because hashing is a kind of encryption. Confusing the two leads directly to the mistake of "encrypting" passwords, or expecting to recover data from a hash.

Encryption Algorithms

Algorithm Comparison

Primitives This Chapter Does Not Cover

The five algorithms above are the classics, but a working system in 2026 needs several primitives that are not among them. They are listed here so you know what to go and read about:

• Elliptic-curve cryptography (ECC): ECDSA and Ed25519 for signatures, ECDH/X25519 for key agreement. Far smaller keys than RSA for equivalent security — a 256-bit curve matches 3072-bit RSA — and much faster.
• Diffie-Hellman key agreement: how two parties derive a shared secret over a public channel. Ephemeral DH (DHE/ECDHE) is what gives modern TLS its forward secrecy.
• ChaCha20-Poly1305: an AEAD stream cipher, faster than AES on hardware without AES-NI. Widely used in TLS and in WireGuard.
• HMAC: the correct way to authenticate a message with a shared secret and a hash function. Never hand-roll H(secret || message).
• Key derivation functions: HKDF for deriving keys from existing key material; Argon2id, scrypt or bcrypt for deriving keys from passwords. These are not interchangeable.

Post-Quantum Cryptography

Every asymmetric algorithm on this page — RSA, and the elliptic-curve schemes above — rests on a problem that a sufficiently large quantum computer solves efficiently. Shor's algorithm factors integers and computes discrete logarithms in polynomial time, which breaks RSA, DH, ECDH and ECDSA at every key size. Increasing the key length does not help.

Symmetric cryptography is far less affected. Grover's algorithm gives only a quadratic speedup on brute-force search, so it notionally halves effective key length: AES-256 retains about 128 bits of security, and SHA-256 remains sound. This is the main reason AES-256 is now preferred over AES-128 for long-lived data.

The threat is not purely future-tense. Harvest-now-decrypt-later means an adversary can record encrypted traffic today and decrypt it once quantum hardware arrives — so anything that must stay confidential for a decade or more is already at risk.

The standards

NIST finalized its first post-quantum standards in August 2024, after an eight-year public competition:

Two standards for signatures is deliberate. ML-DSA is efficient but lattice-based, like ML-KEM; if lattice assumptions were ever broken, SLH-DSA depends only on hash functions and would survive.

What this means in practice

• It has already started. Chrome and Firefox have defaulted to the hybrid key-exchange group X25519MLKEM768 since 2024–25. "Hybrid" means classical X25519 and post-quantum ML-KEM are both run and their secrets combined, so the connection is safe unless both are broken. Your browser is very likely negotiating this right now.
• Timelines are set. NIST IR 8547 (draft) proposes deprecating RSA-2048 and 256-bit ECC after 2030 and disallowing them after 2035. NSA's CNSA 2.0 suite requires post-quantum algorithms for national security systems on a similar schedule.
• Key exchange first, signatures later. Key exchange is urgent because of harvest-now-decrypt-later. Signatures are less urgent — a signature forged in 2040 cannot retroactively compromise a 2026 session — but certificate chains take years to migrate.
• Do not roll your own. Use your TLS library's PQ support rather than implementing lattice cryptography.

Algorithm Selection Guide

For encrypting data:

• Use AES-256-GCM, or ChaCha20-Poly1305 where AES hardware acceleration is unavailable. Both are AEAD modes — they authenticate as well as encrypt.
• To encrypt something larger than a few hundred bytes with a public key, use hybrid encryption: encrypt the data with AES and encrypt only the AES key asymmetrically.

For key exchange:

• Use ECDHE / X25519, ideally the hybrid post-quantum group X25519MLKEM768.
• Do not use RSA key transport. TLS 1.3 removed it because it provides no forward secrecy: one compromised private key exposes every recorded past session.

For digital signatures:

• Ed25519 for new designs; RSA-PSS (3072-bit or larger) where RSA is required for interoperability.
• Plan a migration path to ML-DSA.

For hashing and integrity:

• Use SHA-256 or SHA-3. Use HMAC, not a bare hash, whenever a secret key is involved.
• Avoid MD5 and SHA-1 for anything an adversary can influence.

For passwords:

• Use Argon2id, scrypt, or bcrypt. Never SHA-256, salted or otherwise — general-purpose hashes are far too fast for this job.

For legacy systems:

• DES and 3DES are disallowed and should only ever be decrypted, never used to encrypt new data.

What's Next?

Now that you understand encryption algorithms, explore related topics:

• String Algorithms - String processing techniques
• Machine Learning Algorithms - ML algorithms and techniques