Types of Cryptography: Symmetric, Asymmetric, and Hash Functions Explained

Whenever someone asks me to explain cryptography from scratch, I always start with the same map: there are really three foundational pillars, and almost everything else in the field is built from combinations of them. Those pillars are symmetric encryption, asymmetric (public key) encryption, and hash functions. In this article, I want to lay out how these three types relate to each other, where each one fits into real systems, and the mathematical logic that separates them.

Why Categorizing Cryptography Matters

I’ve found that people who struggle with cryptography usually aren’t confused about the math — they’re confused about which tool solves which problem. Encryption solves confidentiality. Hashing solves integrity and, combined with signatures, authenticity. Getting this mental model straight before diving into algorithm details makes everything downstream far easier to understand.

Table: The Three Pillars at a Glance

Symmetric Cryptography

Symmetric cryptography is the oldest form of encryption, tracing back conceptually to the Caesar cipher, where Julius Caesar reportedly shifted each letter of a message by a fixed number of positions. The same shift value both encrypts and decrypts the message — which is the essence of every symmetric system since.

Formally:

$$C = E_K(P), \quad P = D_K(C)$$

Modern symmetric algorithms like AES process data using substitution-permutation networks, applying rounds of nonlinear substitution and diffusion to obscure the relationship between plaintext, key, and ciphertext. I described AES’s internal SubBytes, ShiftRows, MixColumns, and AddRoundKey operations in depth elsewhere, but the key takeaway for this article is architectural: one key does both jobs, so both parties must already share that key securely before communication can happen.

Strengths and Limitations

The obvious strength of symmetric cryptography is speed — AES can encrypt data at multiple gigabytes per second with hardware acceleration. The obvious weakness is key distribution: if I want to securely communicate with 100 different people using purely symmetric cryptography, I need 100 different shared secret keys, and I need a secure channel to exchange each one in the first place. This is called the key distribution problem, and it’s the exact gap asymmetric cryptography was invented to fill.

$$\text{Number of keys needed for } n \text{ parties} = \frac{n(n-1)}{2}$$

For just 10 people to communicate securely with each other pairwise, that’s 45 separate keys to manage.

Asymmetric (Public Key) Cryptography

Asymmetric cryptography, introduced conceptually by Whitfield Diffie and Martin Hellman in 1976 and then realized concretely by RSA in 1977, solves the key distribution problem elegantly. Each participant generates a mathematically linked key pair: a public key that can be broadcast to anyone, and a private key that never leaves their possession.

$$C = E_{PubK}(P), \quad P = D_{PrivK}(C)$$

This works because of trapdoor functions — mathematical problems that are easy to compute in one direction and computationally infeasible to reverse without secret information. RSA relies on the difficulty of factoring large integers; ECC relies on the elliptic curve discrete logarithm problem.

Diffie-Hellman Key Exchange

I consider Diffie-Hellman the conceptual ancestor of all modern asymmetric cryptography, even though it’s technically a key exchange protocol rather than an encryption scheme. Two parties agree publicly on a large prime p and a generator g, then:

• Alice picks a private value a, computes A = g^a mod p, and sends A to Bob.
• Bob picks a private value b, computes B = g^b mod p, and sends B to Alice.
• Alice computes the shared secret: S = B^a mod p
• Bob computes the shared secret: S = A^b mod p

Both arrive at:

$$S = g^{ab} \bmod p$$

An eavesdropper who intercepts A and B cannot feasibly compute S because doing so requires solving the discrete logarithm problem.

Strengths and Limitations

Asymmetric cryptography solves key distribution beautifully — I can publish my public key anywhere, and anyone can use it to send me a confidential message that only I can decrypt. The cost is computational: RSA and ECC operations are anywhere from 100 to 1000 times slower than symmetric encryption for equivalent-sized data, which is precisely why real systems almost never use asymmetric encryption to protect bulk data directly.

Hash Functions

Hash functions form the third pillar, and they solve a different problem entirely: not confidentiality, but integrity and fingerprinting. A cryptographic hash function takes an input of arbitrary size and deterministically produces a fixed-size output.

$$H: {0,1}^* \rightarrow {0,1}^n$$

Unlike encryption, hashing is a one-way operation — there’s no key involved, and there’s no way to “decrypt” a hash back into its original input. I use hash functions to verify that data hasn’t changed, to build digital signatures efficiently, and (in keyed forms like HMAC) to authenticate messages.

HMAC: Combining Hashing with a Secret Key

A plain hash function alone doesn’t provide authentication because anyone can compute H(m) for any message m. HMAC (Hash-based Message Authentication Code) solves this by incorporating a secret key:

$$HMAC(K, m) = H((K \oplus opad) | H((K \oplus ipad) | m))$$

Where opad and ipad are fixed padding constants. HMAC lets two parties who share a secret key verify both that a message wasn’t tampered with and that it genuinely came from someone who knows the shared key.

How the Three Types Work Together

I want to emphasize something that took me a while to internalize: real-world systems almost never use just one of these three types in isolation. Consider what happens during a single HTTPS connection to a website:

1. Asymmetric cryptography authenticates the server (via its certificate, signed using RSA or ECDSA) and establishes a shared secret through an ECDHE key exchange.
2. Symmetric cryptography (typically AES-GCM or ChaCha20-Poly1305) then encrypts the actual data flowing between browser and server, because it’s fast enough to handle real-time traffic.
3. Hash functions are used throughout — in the certificate’s digital signature, in the key derivation process, and in the authentication tag that verifies each encrypted packet hasn’t been tampered with.

Table: A Single TLS Handshake Mapped to Cryptographic Types

Other Ways I Categorize Cryptography

Beyond the three pillars, I find it useful to think about a few additional distinctions:

• Classical vs modern cryptography — classical ciphers (Caesar, Vigenère, substitution ciphers) relied on obscurity and simple mathematical transformations; modern cryptography relies on computational hardness assumptions that can be formally analyzed.
• Symmetric block vs stream ciphers — within symmetric cryptography, block ciphers (AES) process fixed chunks, while stream ciphers (ChaCha20) process continuous streams of data.
• Deterministic vs probabilistic encryption — deterministic schemes always produce the same ciphertext for the same plaintext and key (which can leak information), while probabilistic schemes incorporate randomness (like an IV) so identical plaintexts produce different ciphertexts each time.
• Symmetric authentication (MAC) vs asymmetric authentication (digital signatures) — MACs require a shared secret and prove authenticity only to someone who also holds that secret, while digital signatures use a private key and allow anyone with the public key to verify authenticity, making signatures non-repudiable.

A Brief History of How These Types Emerged

I find the historical progression genuinely useful for understanding why these three types exist as separate categories rather than one unified approach. For thousands of years, all cryptography was symmetric by necessity — the Caesar cipher, the Vigenère cipher, and even early 20th-century mechanical systems like the Enigma machine all relied on a single shared secret configuration known to both sender and receiver. The fundamental limitation of this era was never really about the strength of the ciphers themselves but about the logistics of securely distributing that shared secret in the first place, especially across battlefields, oceans, and enemy-monitored communication lines.

Everything changed conceptually in 1976, when Whitfield Diffie and Martin Hellman published New Directions in Cryptography, introducing the idea that encryption and decryption didn’t need to use the same key at all. This was a genuinely radical reframing — it meant two parties could establish a shared secret over a public, insecure channel without ever having met or exchanged anything secret beforehand. RSA followed in 1977, providing the first practical realization of a full public-key encryption and signature scheme rather than just a key exchange protocol. Hash functions, meanwhile, evolved somewhat independently, originally as simple checksums for detecting accidental data corruption, only later being formalized with the strict security properties (pre-image resistance, collision resistance) that make them cryptographically meaningful today. Understanding this history helps explain why the three pillars solve genuinely different problems rather than being interchangeable alternatives to each other.

Digital Signatures: Where Hashing and Asymmetric Cryptography Intersect

I think digital signatures deserve their own mention here because they sit precisely at the intersection of two of the three pillars, and understanding that intersection clarifies a lot about how the pillars complement each other in practice. A digital signature isn’t created by encrypting an entire document with a private key — that would be far too slow. Instead, the document is first hashed down to a fixed-size digest using a function like SHA-256, and only that digest is signed using the signer’s private key (RSA or ECDSA). The recipient independently hashes the received document, decrypts (or verifies, in ECDSA’s case) the signature using the signer’s public key, and compares the two digests. A match confirms both the document’s integrity (it wasn’t altered) and its authenticity (it came from someone holding the corresponding private key). This single mechanism — hashing plus asymmetric cryptography — underlies everything from code-signing certificates to the way cryptocurrency transactions are authorized.

Post-Quantum Cryptography: A Fourth Category Emerging

I’d be doing this topic a disservice if I didn’t mention where the field is heading. Both RSA and ECC rely on mathematical problems (factoring and discrete logarithms) that Shor’s algorithm can solve efficiently on a sufficiently powerful quantum computer. In response, NIST has standardized new algorithms based on different hard problems — lattice-based cryptography (CRYSTALS-Kyber for key exchange, CRYSTALS-Dilithium for signatures) and hash-based signatures (SPHINCS+) — that are believed to resist quantum attacks. Symmetric cryptography and hash functions are comparatively less affected by quantum computing; Grover’s algorithm only halves their effective security, which is why doubling key/output lengths (AES-256, SHA-384/512) is generally considered sufficient mitigation.

Real-World Applications Organized by Type

• Symmetric cryptography: disk encryption (BitLocker, FileVault), VPN tunnels, database encryption at rest, bulk file encryption.
• Asymmetric cryptography: TLS certificates, SSH key authentication, PGP email encryption, cryptocurrency wallets and transaction signing.
• Hash functions: password storage (via specialized KDFs), file integrity verification, blockchain block linking, digital signature generation, Git commit identification.

Best Practices I Follow

• Use symmetric encryption for bulk data — it’s faster and just as secure at appropriate key lengths.
• Use asymmetric cryptography for key exchange and digital signatures, not for encrypting large payloads directly.
• Always pair encryption with an integrity mechanism (AEAD modes like GCM, or a separate HMAC) — encryption alone doesn’t guarantee data hasn’t been tampered with.
• Never build a security-critical system with a plain (unkeyed) hash function when you actually need message authentication — use HMAC instead.
• Stay current on post-quantum cryptography standards for systems protecting long-term-sensitive data.

Common Mistakes I See

• Confusing hashing with encryption — hashing is one-way and can’t be reversed.
• Using symmetric encryption alone in scenarios requiring secure key exchange between strangers, without an asymmetric mechanism to bootstrap the shared key.
• Assuming a hash function alone provides authentication when no secret key is involved.
• Using outdated or broken algorithms (DES, MD5, SHA-1) out of habit or legacy compatibility concerns.
• Overlooking the performance implications of choosing asymmetric cryptography for tasks better suited to symmetric algorithms.

Frequently Asked Questions

Which type of cryptography is “the most secure”? This isn’t a meaningful comparison on its own — each type solves a different problem. A well-implemented AES-256 system, a well-implemented RSA-4096 or ECC P-256 system, and SHA-256 are all considered secure for their respective purposes when used correctly.

Can hash functions be used for encryption? Not directly, since hashing is one-way. However, hash functions are core building blocks inside many encryption and key-derivation schemes, and constructs like counter-mode hashing can even build stream ciphers from them.

Why do I need both symmetric and asymmetric cryptography in one system? Because they solve complementary problems — asymmetric cryptography solves secure key exchange without a pre-shared secret, while symmetric cryptography then handles bulk data efficiently once that shared secret exists.

Is quantum computing going to break all cryptography? Not all of it. Quantum computing primarily threatens asymmetric algorithms based on factoring and discrete logarithms (RSA, ECC, Diffie-Hellman). Symmetric algorithms and hash functions are far more resistant, generally requiring only larger key/output sizes to remain secure.

Do I need to understand the math behind each type to use cryptography safely? Not in depth — I rarely implement cryptographic primitives from scratch myself, and I’d actively discourage most developers from doing so. What matters far more in practice is understanding which category of tool solves which problem, choosing well-audited libraries and standardized algorithms, and avoiding the common implementation mistakes (like reusing nonces or skipping salts) that account for the overwhelming majority of real-world cryptographic failures I’ve seen, far more often than any flaw in the underlying mathematics itself.

Summary

Cryptography, at its core, isn’t a single monolithic discipline — it’s built from three complementary pillars. Symmetric cryptography offers speed and efficiency for bulk data but struggles with key distribution. Asymmetric cryptography solves that distribution problem elegantly through mathematically linked key pairs but at a significant performance cost. Hash functions provide integrity verification and, in keyed forms, message authentication, without the concept of a shared secret being strictly necessary for basic verification. Nearly every real-world secure system — from HTTPS to encrypted messaging apps — weaves all three together, each handling the part of the problem it’s best suited for.

References

• Diffie, W., & Hellman, M. (1976). New Directions in Cryptography. IEEE Transactions on Information Theory.
• NIST FIPS 197, Advanced Encryption Standard (AES)
• NIST FIPS 186-5, Digital Signature Standard (DSS)
• NIST FIPS 180-4, Secure Hash Standard (SHS)
• RFC 2104, HMAC: Keyed-Hashing for Message Authentication
• RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
• NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process