What Problems Does Cryptography Actually Solve?

1. Why Should You Care?

A developer encrypts user passwords with AES. Another signs API requests with MD5. A third uses RSA to encrypt gigabytes of video files.

All three are wrong.

Not because these algorithms are broken, but because they’re using the wrong tool for the job. It’s like using a hammer to cut wood—the hammer works fine, you’re just using it incorrectly.

Cryptography isn’t one thing. It’s a toolbox where each tool solves a specific problem. Use encryption where you need hashing, or hashing where you need signatures, and your “secure” system becomes a liability.

2. Definition

Cryptography is the science of securing information through mathematical techniques. It provides solutions to exactly four fundamental security problems:

1. Confidentiality: Keeping secrets secret
2. Integrity: Detecting unauthorized modifications
3. Authentication: Verifying identity
4. Non-repudiation: Preventing denial of actions

Each problem requires different tools. No single algorithm solves all four.

3. The Four Pillars of Cryptographic Security

Confidentiality: “Only the intended recipient can read this”

The Problem: You want to send a message that only Alice can read, even if Eve intercepts it.

The Solution: Encryption

• Symmetric encryption (AES, ChaCha20)
• Asymmetric encryption (RSA, ECIES)

What It Does NOT Solve:

• Whether the message was tampered with
• Whether the sender is who they claim to be
• Whether the sender can deny sending it

# Confidentiality: AES encryption
ciphertext = aes_encrypt(plaintext, key)
# Eve intercepts ciphertext but cannot read it
# But: Eve could modify the ciphertext without detection!

Integrity: “This message hasn’t been tampered with”

The Problem: You receive a message and need to verify it hasn’t been modified in transit.

The Solution: Hash functions and MACs

• Hash functions (SHA-256, SHA-3)
• Message Authentication Codes (HMAC)

What It Does NOT Solve:

• Keeping the message content secret
• Proving who sent the message (for hashes without keys)

# Integrity: Hash verification
original_hash = sha256(message)
# Later...
if sha256(received_message) != original_hash:
    raise TamperedMessageError()
# But: Anyone can compute a hash—this doesn't prove who sent it!

Authentication: “This message is from who it claims to be from”

The Problem: You receive a message claiming to be from Alice. How do you verify it’s really from her?

The Solution: Digital signatures and MACs

• Digital signatures (RSA-PSS, ECDSA, EdDSA)
• HMAC (with shared secret)

The Difference:

• HMAC: Both parties share a secret key. You know it’s from someone who knows the key.
• Digital Signature: Only the private key holder can sign. You can verify with the public key.

# Authentication: Digital signature
signature = sign(message, alice_private_key)
# Anyone can verify
is_authentic = verify(message, signature, alice_public_key)

Non-Repudiation: “The sender cannot deny sending this”

The Problem: Alice sends you a contract. Later, she claims she never sent it. How do you prove she did?

The Solution: Digital signatures (only asymmetric!)

Why HMAC doesn’t work: With HMAC, both parties share the same key. If Alice has the key, you also have the key—either of you could have created the message. Alice can claim you wrote it.

Why Digital Signatures work: Only Alice’s private key can create a valid signature. If the signature verifies with her public key, it had to come from her private key. She cannot deny it.

# Non-repudiation: Only asymmetric signatures provide this
signature = sign(contract, alice_private_key)
# Alice cannot claim she didn't sign—only her private key could create this signature

4. The Algorithm-Problem Matrix

*Hash provides integrity verification only if you have a trusted copy of the original hash.

5. Common Disasters from Misuse

Disaster 1: Encrypting Passwords

# WRONG: Encryption for password storage
encrypted_password = aes_encrypt(password, key)
database.store(encrypted_password)

# Problem: If the key is stolen, ALL passwords are exposed instantly
# Also: Why do you need to decrypt passwords anyway?

Correct approach: Hash passwords with bcrypt/argon2. You never need to recover the original—you only need to verify.

Disaster 2: Hashing for Confidentiality

# WRONG: Using hash for "encryption"
"secure_data" = sha256(sensitive_data)

# Problem: Hash is one-way, but deterministic
# Same input = same output = pattern analysis possible
# And you can NEVER recover the original data

Correct approach: Use actual encryption if you need to recover the data.

Disaster 3: HMAC for Non-Repudiation

# WRONG: Using HMAC for contracts
mac = hmac(contract, shared_secret)

# Problem: Both parties have the key
# Alice: "I didn't sign this—Bob has the same key, he could have written it"

Correct approach: Use digital signatures for anything requiring non-repudiation.

Disaster 4: RSA-Encrypting Large Data

# WRONG: Encrypting large files with RSA
encrypted_video = rsa_encrypt(video_file, public_key)  # Extremely slow!

# Problem: RSA is ~1000x slower than AES
# Also: RSA has message size limits

Correct approach: Use hybrid encryption—encrypt data with AES, encrypt the AES key with RSA.

6. How Real Systems Combine Tools

Real-world security requires multiple cryptographic primitives working together.

HTTPS/TLS Handshake

┌─────────────────────────────────────────────────────────┐
│ 1. Key Exchange (Confidentiality + Authentication)      │
│    - ECDHE for forward secrecy                         │
│    - Server certificate (RSA/ECDSA signature)          │
├─────────────────────────────────────────────────────────┤
│ 2. Data Transfer (Confidentiality + Integrity)         │
│    - AES-GCM encryption                                │
│    - Built-in authentication tag (integrity)           │
└─────────────────────────────────────────────────────────┘

JWT (JSON Web Token)

┌─────────────────────────────────────────────────────────┐
│ Header.Payload.Signature                               │
├─────────────────────────────────────────────────────────┤
│ Signature provides:                                    │
│ - Integrity: Token cannot be modified                  │
│ - Authentication: Server can verify issuer             │
├─────────────────────────────────────────────────────────┤
│ Signature does NOT provide:                            │
│ - Confidentiality: Payload is Base64, not encrypted!   │
└─────────────────────────────────────────────────────────┘

7. Decision Framework

When choosing cryptographic tools, ask:

Do you need to recover the original data?
├─ NO → Consider hashing
│   └─ Is it a password? → Use bcrypt/argon2
│   └─ Is it for integrity? → Use SHA-256/SHA-3
│
├─ YES → You need encryption
│   └─ Who has the key?
│       ├─ Same party encrypts/decrypts → Symmetric (AES)
│       └─ Different parties → Asymmetric or Hybrid
│
Do you need to prove who sent it?
├─ Shared secret acceptable? → HMAC
└─ Need non-repudiation? → Digital Signature

8. Summary

Three things to remember:

1. One algorithm, one problem. Encryption provides confidentiality. Hashing provides integrity. Signatures provide authentication and non-repudiation. Don’t mix them up.

2. Non-repudiation requires asymmetric cryptography. If both parties share a key, neither can prove the other sent a message. Only digital signatures provide non-repudiation.

3. Real systems combine multiple primitives. HTTPS uses key exchange, encryption, and authentication together. Understanding which tool does what helps you understand why protocols are designed the way they are.

9. What’s Next

Now we understand the four problems cryptography solves. But we’ve mentioned “symmetric” and “asymmetric” encryption several times without explaining the difference.

In the next article, we’ll explore: Why do we need two completely different types of encryption? What are their trade-offs, and how do real systems combine them?