Cryptography Basics: Hashing, Encryption and TLS

The first rule of cryptography, repeated so often it's become a cliché, is don't roll your own. It's good advice and it's also slightly misleading, because it makes people think cryptography is something they can leave entirely to specialists. You can't. Every developer, every systems administrator and every founder choosing a SaaS product makes cryptographic decisions constantly — which library, which mode, which key length, whether "encrypted" in the brochure means anything. The mathematics is for specialists. The choices are yours. This post covers the cryptography basics that every builder needs and no one gets taught.

This post is the working knowledge I wish someone had handed me at the start: what the main primitives do, what to pick in 2026, and the mistakes I keep seeing.

Part 6 of 10 · Foundations of Infosec. Previous: Least Privilege & Zero Trust. Next: Defence in Depth.

Key takeaways

Cryptography basics in one line: hashes for integrity, encryption for confidentiality, signatures for authenticity.
Use SHA-256, Argon2id for passwords, AES-GCM or ChaCha20-Poly1305, X25519/Ed25519, TLS 1.3.
Never ECB, never MD5/SHA-1, never reuse a GCM nonce, never keys in source code.
Encryption at rest turns a data problem into a key-management problem — manage the keys.

Cryptography basics: what it gives you

Map the tools onto the properties from the CIA triad:

Confidentiality — encryption. Only holders of the key can read the data.
Integrity — hashes and message authentication codes. Any change to the data is detectable.
Authenticity and non-repudiation — digital signatures. The data provably came from a specific key holder.

Almost everything else — TLS, disk encryption, password storage, code signing, cryptocurrencies — is a combination of those three built into a protocol.

Hashing: fingerprints for data

A cryptographic hash function takes input of any size and produces a fixed-size output — a digest — with three properties: the same input always gives the same digest; it's infeasible to find an input that produces a given digest; and it's infeasible to find two inputs with the same digest. Change one bit of the input and the digest changes completely.

Hashes are for integrity. Download a file, hash it, compare to the published digest: if they match, the file is intact. Git identifies every commit by a hash. Certificate transparency logs, blockchains and deduplication systems all lean on the same property.

What to use: SHA-256 (or the SHA-2 family generally) and SHA-3. MD5 and SHA-1 are broken for collision resistance — researchers produced practical SHA-1 collisions in 2017 — and should not be used for anything security-relevant. If you see MD5 in a new design, that's a finding.

Passwords are a special case

Storing passwords is not an ordinary hashing problem, and this is where I see the most damage. A fast hash like SHA-256 is designed to be fast; an attacker with a leaked database and a graphics card can test billions of candidate passwords per second against it. Adding a salt (random per-password data) stops precomputed tables and stops identical passwords having identical hashes, but doesn't slow the attacker down.

For passwords you need a hash that is deliberately slow and memory-hungry: Argon2id (winner of the 2015 Password Hashing Competition and the current recommendation), scrypt, or bcrypt. These let you tune the cost so that a legitimate login takes tens of milliseconds while an attacker's cracking rig manages only thousands of guesses per second instead of billions. OWASP's Password Storage Cheat Sheet gives current parameters.

Symmetric encryption: one key, both directions

Symmetric encryption uses the same key to encrypt and decrypt. It's fast — modern CPUs have hardware instructions for it — and it's what actually protects the bulk of data everywhere: your disk, your database backups, the body of every TLS connection.

What to use: AES with a 256-bit key (AES-128 is also fine; the difference matters mostly against hypothetical future quantum computers) or ChaCha20, which performs better on devices without AES hardware.

The trap is the mode of operation. AES on its own encrypts one 16-byte block. To encrypt a message you need a mode that chains blocks, and the choice matters enormously:

ECB — encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks; patterns leak straight through. The famous "ECB penguin" image, where an encrypted bitmap is still recognisably a penguin, makes the point. Never use ECB.
CBC — better, but provides no integrity; attackers can flip bits in the ciphertext with predictable effects on the plaintext, and "padding oracle" attacks have broken CBC deployments repeatedly.
GCM and ChaCha20-Poly1305 — authenticated encryption. They provide confidentiality and integrity together, so any tampering is detected before decryption. This is what you want. If your library offers AES-GCM or ChaCha20-Poly1305, use it and stop thinking about modes.

Two further rules. Never reuse a nonce (the per-message random value) with the same key under GCM; doing so catastrophically breaks it. And generate keys and nonces from a cryptographically secure random source (/dev/urandom, crypto.randomBytes, secrets in Python) — never from Math.random() or a timestamp.

Asymmetric encryption and signatures: two keys

Symmetric encryption has a distribution problem: both parties need the same secret key, and you can't send it over the channel you're trying to protect. Public-key cryptography, invented in the 1970s, solves this with a key pair: a public key anyone may have and a private key only you hold. Encrypt with the public key, decrypt with the private; or sign with the private, verify with the public.

Asymmetric operations are slow, so they're used sparingly: to agree a symmetric key at the start of a session (key exchange), and to sign things. Nobody encrypts a gigabyte with RSA.

What to use: for key exchange, elliptic-curve Diffie–Hellman (X25519 is the modern default); for signatures, Ed25519 or ECDSA with P-256; RSA with keys of at least 2048 bits (3072 preferred) where compatibility demands it. Keys shorter than that, and anything using the DSA or the older 1024-bit RSA, are obsolete.

Digital signatures are how you get authenticity at scale. Software updates are signed so your device can verify they came from the vendor. Certificates are signed by certificate authorities. Git commits can be signed. JWTs are signed (and here lies a well-known trap: a JWT library that accepts alg: none, or that lets an attacker swap an asymmetric algorithm for a symmetric one, has thrown the signature away — always pin the algorithm you expect).

TLS: the protocol you use a billion times a day

Transport Layer Security is the assembly of all of the above into a channel: certificates (signatures) establish who you're talking to, a key exchange sets up a fresh symmetric key, and authenticated encryption protects the traffic. It's the "S" in HTTPS and it secures email, messaging, VPNs and most API traffic.

What to use in 2026: TLS 1.3, with TLS 1.2 kept only for clients that genuinely can't do better. TLS 1.0 and 1.1 were formally deprecated in 2021 (RFC 8996) and should be off. TLS 1.3 removed every known-weak option — RSA key exchange, CBC modes, RC4, SHA-1 — so there's very little to misconfigure. Mozilla publishes a configuration generator that gives you a correct server config for any common web server; use it rather than hand-tuning cipher lists.

Certificates come from a certificate authority your users' browsers already trust, and since Let's Encrypt they're free and automated. There is no longer any excuse for an expired certificate, which remains one of the most common causes of "the site is down" and a genuine availability failure. Automate renewal and monitor expiry.

Two properties worth knowing by name: forward secrecy (each session uses a fresh ephemeral key, so compromising the server's long-term key later doesn't decrypt recorded traffic — standard in TLS 1.3) and HSTS (a header telling browsers to always use HTTPS for your domain, closing the window for downgrade attacks).

Encryption at rest: what it does and doesn't protect

"Data encrypted at rest" appears in every vendor's security page. It's worth being precise about what it means.

Full-disk encryption (BitLocker, FileVault, LUKS) protects against a lost or stolen device. When the machine is running and unlocked, the data is in the clear to any process on it. It does nothing against malware or a compromised account. It is still essential for every laptop and phone, because devices are lost constantly.

Database and storage encryption in the cloud (AWS S3 default encryption, RDS encryption, and so on) protects against someone walking off with the physical disks from the data centre — a threat the cloud provider is far better placed to worry about than you. It does not protect against an attacker who has your credentials, because your application decrypts transparently. It's still worth turning on: it's free, it satisfies auditors, and it forces key management discipline.

Application-level encryption — encrypting specific fields with keys the application controls, ideally in a key management service or HSM — is what actually limits damage from a compromised database. It's also the hardest to do well, because now you must manage keys, rotation and access to the KMS. Reserve it for the data that genuinely warrants it: payment details, health records, secrets.

The honest summary: encryption at rest converts a data-protection problem into a key-management problem. If the key sits next to the data — in a config file on the same server, in an environment variable everyone can read — you have decoration, not protection. Use your cloud's KMS, restrict who and what can call it, and log every use.

The mistakes that keep recurring

Having reviewed a lot of systems, the failures cluster:

Home-made constructions. Combining primitives by hand — "we encrypt with AES-CBC and then append an MD5" — almost always has a subtle flaw. Use a high-level library (libsodium, Google Tink, the platform's authenticated-encryption API) that makes the right choices for you.
Weak randomness. Keys, tokens and nonces generated from non-cryptographic sources.
Keys in the wrong place. Hard-coded in source, committed to Git, in a Slack message. Secret scanning finds these daily.
Obsolete algorithms that "still work": MD5, SHA-1, DES/3DES, RC4, RSA-1024, TLS 1.0.
Verification skipped for convenience. Certificate validation disabled in a client "to make the integration work". Signature checks wrapped in a try/except that ignores failure.
Confusing encoding with encryption. Base64 is not encryption. Neither is XOR with a fixed key. Neither is "obfuscation".

On quantum computers, briefly

A sufficiently large quantum computer would break RSA and elliptic-curve cryptography, which underpin key exchange and signatures. No such machine exists today, and estimates of when one might vary widely. But data recorded now can be decrypted later, which is why NIST finalised its first post-quantum standards in August 2024 (FIPS 203, ML-KEM for key exchange, and FIPS 204, ML-DSA for signatures), and why major browsers and CDNs began deploying hybrid post-quantum key exchange in TLS in 2024. Symmetric encryption and hashing are much less affected; AES-256 and SHA-256 remain fine.

For most organisations the action item is simple: track it, prefer software and providers that are adopting the new standards, and make sure you could change algorithms — which is really a question of whether your cryptography is centralised in libraries and services or scattered through hand-written code.

The checklist

If you build or run systems, this is the short version to keep beside you:

Hashing: SHA-256 or SHA-3. Passwords: Argon2id, scrypt or bcrypt, salted, tuned to be slow.
Symmetric: AES-GCM or ChaCha20-Poly1305. Never ECB. Never reuse a nonce.
Asymmetric: X25519 for exchange, Ed25519 or ECDSA P-256 for signatures, RSA ≥ 2048 where required.
Transport: TLS 1.3, automated certificates, HSTS on.
At rest: disk encryption everywhere; cloud storage encryption on; application-level encryption with a KMS for the crown jewels.
Keys: generated from a CSPRNG, stored in a secrets manager or KMS, rotated, never in code.
Libraries: use a high-level one that makes the choices for you.

Get those right and your cryptography will not be the weakest part of your system. It almost never is; the weak part is always the key on the sticky note.

Further reading

NIST SP 800-57 — Recommendation for Key Management
NIST FIPS 203 / 204 / 205 — post-quantum standards (2024)
OWASP Password Storage Cheat Sheet and Cryptographic Storage Cheat Sheet
Mozilla SSL Configuration Generator — ssl-config.mozilla.org
RFC 8446 — TLS 1.3; RFC 8996 — Deprecating TLS 1.0 and 1.1
Jean-Philippe Aumasson, Serious Cryptography (2nd ed., No Starch Press, 2024)

This series