Cryptography Made Simple

Cryptography sounds like math, but as a working engineer you almost never write the math. Your job is to pick the right tool for the right goal and not misuse it. So forget the equations and learn crypto by its three purposes. Cryptography (from Greek "hidden writing") is the science of protecting information so that only the people who should read or trust it can. Everything below serves one of three goals:

Confidentiality

Only the intended reader can see the content. (Tool: encryption.)

Integrity

The content was not changed, even by one bit. (Tool: hashing.)

Authenticity

It really came from who it claims to be from. (Tool: digital signatures.)

3.1 Encoding vs Hashing vs Encryption — the #1 confusion

These three words get mixed up constantly, and that confusion has caused real breaches. They are completely different things.

Encoding

A reversible reformatting with no secret involved. Examples: Base64, URL-encoding, ASCII. Purpose is transport/format, never security. Anyone can decode it. Analogy: translating English into Morse code — no secret, anyone with the chart reads it.

Hashing

A one-way fingerprint. The same input always produces the same fixed-length output; you cannot reverse it back to the original. A hash function like SHA-256 turns any input into 256 bits (64 hex characters). A tiny change in input flips most of the output bits — this is the avalanche effect. Analogy: blending fruit into a smoothie — you cannot un-blend it back into the original fruit.

Encryption

A reversible scramble that needs a key. Purpose is confidentiality. Without the key, the output (called ciphertext) is useless gibberish; with the key, you get the exact original back. Analogy: a locked box — the key opens it, nobody else can.

3.2 Symmetric Encryption (AES) — one shared key

Symmetric encryption uses one secret key for both encrypting and decrypting. It is fast, so it is what actually protects bulk data (files, disks, the body of a web request). The standard is AES (Advanced Encryption Standard), adopted in 2001, with 128-, 192-, or 256-bit keys. AES-256 is the everyday workhorse.

But how you run AES matters enormously — this is the mode of operation. Never use ECB (Electronic Codebook) mode: it encrypts each block independently, so identical plaintext blocks produce identical ciphertext, leaking the data's patterns. The famous "ECB Penguin" demo shows an image still clearly recognizable after ECB "encryption." Instead use authenticated modes — AES-256-GCM or ChaCha20-Poly1305 — which give confidentiality and integrity together (they detect tampering).

Symmetric crypto has one big problem: two strangers on an open network must somehow agree on the same secret key without an eavesdropper learning it. That problem is solved by public-key crypto and key exchange.

3.3 Asymmetric / Public-Key Crypto (RSA, ECC) and Key Exchange

Asymmetric encryption uses a key pair: a public key (shareable with anyone) and a private key (kept secret). Anyone can encrypt a message to you using your public key, but only your private key can decrypt it.

RSA (1977) relies on the difficulty of factoring huge numbers and needs big keys (2048 or 4096 bits) — secure but slow. ECC (Elliptic Curve Cryptography) gives the same security with far smaller keys (a 256-bit ECC key ≈ a 3072-bit RSA key), so it is faster and now dominates TLS.

Asymmetric crypto is slow, so in practice it is used only to set up a shared symmetric key, then fast AES does the bulk work. This is hybrid encryption, and it is how essentially all secure connections work.

Diffie-Hellman (DH) key exchange (1976) lets two parties derive the same shared secret over a public channel without ever sending it.

Modern TLS uses ECDHE (Elliptic-Curve Diffie-Hellman Ephemeral). "Ephemeral" means a fresh throwaway key for every session. This gives forward secrecy: even if the server's long-term private key is stolen later, past recorded sessions stay safe because each used a random, discarded key. ECDHE is the default in TLS 1.3.

            ENCRYPTION (private decrypts)        SIGNATURE (private signs)
 Sender --[encrypt w/ recipient PUBLIC key]-->   Signer --[sign hash w/ OWN PRIVATE key]-->
 Recipient --[decrypt w/ OWN PRIVATE key]        Anyone --[verify w/ signer PUBLIC key]
 Goal: CONFIDENTIALITY                           Goal: AUTHENTICITY + INTEGRITY

3.4 Hashing for Integrity vs Hashing for Passwords

General-purpose hashing uses SHA-256 (part of the SHA-2 family; SHA-3 exists as an alternate design). It is used for file-download verification, digital signatures, blockchain, and deduplication. Crucially, SHA-256 is fast by design — perfect for integrity, but terrible for passwords, because an attacker with a GPU can try billions of guesses per second.

For passwords you want slowness. Use a purpose-built password KDF (Key Derivation Function) — an intentionally slow, resource-hungry hash:

Salt

A unique random value per password, stored next to the hash. It defeats rainbow tables (precomputed hash lookup tables) and ensures two users with the same password get different hashes. Non-negotiable — modern KDFs add it automatically.

Pepper

A single secret value shared across all passwords, stored separately from the database (in a KMS/HSM or app config). Even if the entire database leaks, hashes cannot be cracked without the pepper.

3.5 Digital Signatures — proving authenticity and integrity

A digital signature proves a message truly came from a sender and was not altered (it does not hide the content). The signer hashes the message, then encrypts that hash with their private key — that encrypted hash is the signature. Anyone uses the signer's public key to decrypt the signature and compares the result to a fresh hash of the message. If they match, it is authentic and unaltered. Bonus: non-repudiation — the signer cannot later deny it. Notice this is encryption run backwards: private key signs, public key verifies. Signatures power TLS certificates, code signing, and software updates.

3.6 TLS / HTTPS Handshake, Certificates, and Let's Encrypt

TLS (Transport Layer Security) is the protocol behind the padlock in https://. It combines everything above. A simplified TLS 1.3 handshake:

 Browser                                   Server
   | --- ClientHello: ciphers + DH share ---> |
   | <-- ServerHello: chosen cipher,          |
   |     server DH share, CERTIFICATE ------- |
   | --- both compute shared key via ECDHE -- |
   | --- verify cert chains to trusted CA --- |
   | === encrypted traffic (AES/ChaCha20) === |

TLS 1.3 (RFC 8446, 2018) finishes this in one round trip (much faster than 1.2) and removed all the old broken options — no RSA key transport, no ECB, no SHA-1. As of early 2026, TLS 1.3 carries roughly 95% of encrypted web traffic.

A certificate binds a public key to a domain name, vouched for by a Certificate Authority (CA). Browsers ship a trust store of root CAs. The chain of trust runs root CA → intermediate CA → your site's certificate. PKI (Public Key Infrastructure) is the whole ecosystem of CAs, certificates, and revocation.

Let's Encrypt (nonprofit, 2016) made certificates free and automated via the ACME protocol; it now backs a majority of web certs, and over 94% of certs are Domain-Validated and often issued instantly. Certificate lifetimes are shrinking toward ~47 days by 2029 (per the CA/Browser Forum), which makes automated renewal mandatory — never plan to renew certs by hand.

3.7 Key Management, KMS, and HSMs

The hardest part of crypto is not the algorithm — it is protecting the keys. Golden rules: never hardcode keys in source or commit them to Git, never store keys next to the data they protect, rotate keys periodically, and restrict access.

HSM (Hardware Security Module)

A tamper-resistant physical device that generates and stores keys so they never leave the hardware in plaintext. Validated against FIPS 140-3 (Level 3 = physical tamper-resistance).

KMS (Key Management Service)

A managed cloud service (AWS KMS, Azure Key Vault, GCP KMS) that handles keys via API. As of Feb 2025, AWS KMS HSMs reached FIPS 140-3 Level 3, and KMS does automatic annual key rotation.

Envelope encryption

A data key encrypts your data; a master key inside the KMS/HSM encrypts the data key; you store the encrypted data key beside the data. Only the KMS can unwrap it — so a database leak alone exposes nothing usable.

3.8 Data States and Confidential Computing

Historically, data in use was decrypted in memory to compute on it — a gap. Confidential computing closes it with hardware Trusted Execution Environments (TEEs) that encrypt memory and isolate the computation: Intel SGX/TDX, AMD SEV-SNP, AWS Nitro Enclaves, ARM TrustZone. A hot 2025 use case is confidential AI on GPUs, so even the cloud provider cannot read your data while it is being processed.

3.9 Post-Quantum Crypto (PQC) Awareness

A large quantum computer running Shor's algorithm would break RSA and ECC — today's public-key crypto. Symmetric AES-256 and SHA-256 stay largely safe (just use big sizes). On Aug 13, 2024, NIST finalized the first PQC standards: FIPS 203 (ML-KEM, key exchange), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA, backup signatures).

Common mistakes

• Rolling your own crypto. Anyone can design a cipher they can't break themselves. Use vetted libraries (libsodium, your platform's crypto API).
• ECB mode — leaks patterns (the ECB Penguin; Adobe's reused-key 3DES-ECB).
• MD5/SHA-1 or unsalted hashes for passwords (LinkedIn 2012).
• Hardcoded or committed keys in Git, logs, or shipped binaries.
• Encrypting when you should hash (passwords) — or hashing when you need to recover data.
• Weak/missing TLS (SSLv3, TLS 1.0, RC4) and reused nonces in GCM.

Best practices

• Use authenticated encryption: AES-256-GCM or ChaCha20-Poly1305, with a fresh random nonce each time.
• Hash passwords with Argon2id (OWASP profile); rely on the KDF's built-in per-password salt, add a pepper in KMS.
• Use TLS 1.3 everywhere; automate certificate renewal (Let's Encrypt/ACME) ahead of shrinking lifetimes.
• Store keys in a KMS/HSM, never beside the data; rotate keys; use envelope encryption.
• Protect all three data states; consider TEEs for sensitive "in use" workloads.
• Start a PQC inventory now for long-lived secrets and adopt hybrid key exchange where available.