Cryptography is the practice of protecting information by transforming it into a form that’s unreadable to anyone except those it’s intended for. It’s the foundation underneath almost every secure protocol covered elsewhere in these tech corner explainers — TLS, SSH, VPNs, WPA3, and Kerberos all rely on the concepts covered here.
Encryption vs encoding vs hashing
Before going further, it’s worth being precise about three terms that are often confused:
- Encryption transforms readable data (“plaintext”) into unreadable data (“ciphertext”) using a key, and can be reversed back into plaintext by anyone who has the correct key.
- Encoding transforms data into a different format (like Base64) purely for compatibility or transport reasons — it provides no security at all, since no key is required to reverse it. Anyone can decode Base64 instantly; it just isn’t designed to hide anything.
- Hashing transforms data into a fixed-length output, but — critically — cannot be reversed back into the original data at all. It’s used to verify data hasn’t changed, not to keep it secret (covered in detail below).
A surprisingly common real-world security mistake is treating encoding as if it were encryption — Base64-encoding a password and calling it “protected” provides no actual security whatsoever, since decoding it back requires no secret at all.
Symmetric encryption
Symmetric encryption uses the exact same key for both encrypting and decrypting data. Whoever holds that key can do either.
- AES (Advanced Encryption Standard) is by far the most widely used symmetric algorithm today, and appears throughout this site — it’s the “AES” in TLS cipher suites (see the TLS page) and WPA2/WPA3’s AES-CCMP encryption (see the Wi-Fi Protocols page).
- Symmetric encryption is fast and computationally efficient, which is exactly why it’s used to encrypt the actual bulk data in a connection, once a connection has been established.
- Its core weakness is key distribution: both parties need to somehow already share the same secret key before they can communicate securely, and safely getting that key to both sides — without anyone intercepting it along the way — is a genuinely hard problem on its own. This is precisely the problem asymmetric encryption, below, was invented to solve.
Key length
A symmetric key’s length (measured in bits — commonly 128 or 256 for AES) determines how many possible key combinations exist, and therefore how resistant it is to being simply guessed through brute force. AES-256’s 2²⁵⁶ possible keys is an almost incomprehensibly large number — even with all of the world’s current computing power combined, brute-forcing a single correctly generated AES-256 key would take vastly longer than the current age of the universe.
Asymmetric encryption
Asymmetric encryption (also called public-key cryptography) uses two mathematically related keys instead of one: a public key, which can be shared with anyone, and a private key, which must be kept secret.
Data encrypted with someone’s public key can only be decrypted with their matching private key, and — depending on the algorithm — the reverse is often also true: data “signed” with a private key can be verified by anyone holding the corresponding public key (this is the basis of digital signatures, covered below).
- RSA and ECC (Elliptic Curve Cryptography) are the two most common asymmetric algorithms in use today. ECC achieves equivalent security to RSA using much shorter keys, which is why it’s increasingly preferred, particularly on lower-powered devices.
- Asymmetric encryption directly solves symmetric encryption’s key-distribution problem: your public key can be shared completely openly (even published for anyone to see), since only your matching private key can decrypt anything encrypted with it.
- The trade-off is performance — asymmetric encryption is significantly slower and more computationally expensive than symmetric encryption, which is why it’s rarely used to encrypt bulk data directly.
How TLS actually combines both
This is exactly why the TLS handshake (see the TLS page) uses both types together, rather than choosing one: asymmetric encryption is used briefly, during the handshake, specifically to securely agree on a temporary symmetric key — and then that fast symmetric key is what actually encrypts the rest of the session’s data. This same “asymmetric handshake, symmetric bulk encryption” pattern appears throughout this site — SSH key pairs (see the SSH page) work the same way.
Hashing
A hash function takes an input of any size and produces a fixed-length output (called a hash, or digest) that’s unique to that specific input. Unlike encryption, hashing is a one-way process — there’s no key, and no way to reverse a hash back into its original input.
Two properties make hashing useful:
- Determinism: The same input will always produce exactly the same hash, every single time.
- The avalanche effect: Changing even a single character of the input produces a completely different, unrelated-looking hash. This makes hashing extremely effective for detecting whether data has been altered — comparing hashes before and after is far quicker than comparing entire files or messages byte by byte.
SHA-256 (part of the SHA-2 family) is the most widely used modern hashing algorithm, appearing throughout this site’s cipher suite discussions on the TLS page. MD5 and SHA-1, older hashing algorithms, are now considered broken — not because they can be “decrypted” (they were never encryption in the first place), but because researchers have found ways to deliberately construct two different inputs that produce the same hash (a collision), which undermines the whole point of using a hash to verify data hasn’t been tampered with.
Password hashing and salting
Hashing has a particularly important, specific application: storing passwords. A properly built system never stores a user’s actual password — instead, it stores the hash of that password, and checks a login attempt by hashing whatever was typed in and comparing it to the stored hash. This way, even if a database is stolen, an attacker doesn’t get plaintext passwords directly.
However, using a plain, general-purpose hash function like SHA-256 for this specific job has a weakness: since hashing is deterministic, two users with the same password produce the exact same hash, and attackers maintain huge precomputed tables (called rainbow tables) of common passwords and their corresponding hashes, allowing a stored hash to be reverse-looked-up almost instantly if it isn’t protected further.
Salting addresses this by adding a unique, random value (the “salt”) to each password before hashing it, meaning even two identical passwords produce completely different stored hashes, defeating precomputed rainbow tables entirely. Purpose-built password hashing algorithms — bcrypt, scrypt, and Argon2 — go further still, deliberately designed to be slow and computationally expensive (unlike SHA-256, which is deliberately fast), specifically to make brute-forcing large numbers of guesses against a stolen password database impractically slow, even with dedicated cracking hardware.
Digital signatures
A digital signature combines hashing and asymmetric encryption to prove both that a message genuinely came from a specific sender, and that it hasn’t been altered since they sent it.
The process, in simplified form:
- The sender hashes their message, producing a digest.
- The sender encrypts that digest with their own private key — this encrypted digest is the signature.
- Anyone receiving the message can independently hash it themselves, then decrypt the sender’s signature using the sender’s public key, and compare the two results.
- If they match, this proves two things at once: the message genuinely came from someone holding that private key (authenticity), and it hasn’t been altered since it was signed, since even a single changed character would produce a completely different hash (integrity).
This is exactly the mechanism underneath a digital certificate (see the TLS page) — a Certificate Authority digitally signs a website’s certificate using the CA’s own private key, and your browser verifies that signature using the CA’s public key, which came pre-installed as part of your browser’s trusted root store.
PKI: Public Key Infrastructure
PKI (Public Key Infrastructure) is the overall system of certificates, Certificate Authorities, and trust relationships that makes public-key cryptography practical to use at scale across the entire Internet, rather than every single person needing to somehow verify everyone else’s public key individually and manually.
The TLS page already covers the practical mechanics of certificates and the chain of trust in detail — the key underlying idea, now that the cryptographic building blocks above have been properly explained, is that a certificate is really just a digital signature (see above) applied to a public key, vouching that a specific public key genuinely belongs to a specific identity.
Cryptography fundamentals and security
Understanding these building blocks makes it much easier to recognise a handful of recurring, important security principles that show up throughout this site’s protocol coverage.
Algorithm strength matters more than algorithm secrecy. A core principle of modern cryptography (known as Kerckhoffs’s principle) holds that a cryptographic system should remain secure even if everything about how it works is publicly known, with only the key itself kept secret. AES, RSA, and SHA-256 are all completely public, thoroughly studied, standardised algorithms — their security comes entirely from the difficulty of guessing the key, not from anyone keeping the algorithm itself a secret. A system that instead relies on keeping its own custom, undisclosed encryption method secret (sometimes called “security through obscurity”) is generally considered a serious red flag, since it hasn’t been tested by the wider cryptographic community the way public algorithms have.
Key management is usually the weakest link, not the algorithm. AES-256 being effectively unbreakable by brute force (as covered above) means very little if the key itself is stored insecurely, transmitted in the clear, reused indefinitely without rotation, or embedded directly in a device’s firmware where it can simply be extracted. Nearly every practical cryptographic failure in the real world comes down to how keys were generated, stored, or handled — not the underlying maths being broken.
Deprecated algorithms remain a real, ongoing risk. MD5 and SHA-1 (hashing) and older symmetric ciphers like DES and RC4 are now considered insecure, but — much like the older TLS versions covered on the TLS page — they sometimes remain enabled in older systems for compatibility reasons, quietly weakening security for anyone still relying on them.
Quantum computing represents a longer-term, still-developing threat specifically to asymmetric cryptography. A sufficiently powerful quantum computer could, in theory, break RSA and ECC far faster than any classical computer, by exploiting quantum algorithms fundamentally different from brute-force guessing. Symmetric algorithms like AES are considered much more resistant to this specific threat. This has led to active research and early standardisation of post-quantum cryptography — new algorithms designed to remain secure even against quantum attacks — though practical, widespread quantum computers capable of actually breaking today’s RSA/ECC key sizes don’t yet exist.