What Cryptography Actually Is (And Is Not)
This article is the fourth in our cybersecurity fundamentals series. The previous articles covered Types of Hackers, the 8 CISSP Security Domains, and Common Cyber Attack Types. This article explains the cryptographic mechanisms that underpin the defences discussed throughout the series.
Cryptography is the science of securing information by transforming it into a form that only authorised parties can understand. The word comes from the Greek kryptos (hidden) and graphia (writing) — hidden writing. But modern cryptography is not about hiding. It is a branch of mathematics that provides provable security guarantees: when correctly implemented, cryptographic systems can be made so computationally difficult to break that an attacker with all the computing power in the world would need longer than the age of the universe to crack them.
This is a critical distinction from popular misconceptions. Cryptography is not about making information hard to find — that is security through obscurity, a fundamentally weak approach. It is not about keeping algorithms secret — in fact, the strongest cryptographic algorithms are publicly documented and subjected to worldwide academic scrutiny, because security that depends on secrecy about how the algorithm works is fragile. And cryptography is not the same as encryption, though encryption is its most widely used application. Cryptography also encompasses hashing, digital signatures, key exchange protocols, and a growing field of post-quantum algorithms designed to resist attacks from quantum computers.
The reason cryptography matters in 2026 specifically is the convergence of two forces: the increasing digitisation of sensitive data and transactions, and the emerging threat of quantum computing to current cryptographic standards. Understanding cryptography fundamentals is no longer the exclusive domain of security professionals — it is increasingly relevant to anyone who builds, manages, or evaluates digital systems.
Symmetric Encryption: One Key for Everything
Symmetric encryption is the oldest and simplest form of cryptography — and despite its simplicity, it remains one of the two fundamental pillars of modern security systems. In symmetric encryption, the same secret key is used both to encrypt data (convert it from readable plaintext to scrambled ciphertext) and to decrypt it (convert it back). Both the sender and receiver must possess the same key, and that key must be kept completely secret.
The most important symmetric encryption algorithm in use today is AES — the Advanced Encryption Standard. AES was selected by NIST in 2001 following an open international competition and has since become the global standard for symmetric encryption. It operates on data in fixed 128-bit blocks, using a key of 128, 192, or 256 bits. AES-256 is the most widely recommended variant, providing a security margin so large that a brute-force attack — trying every possible key — would require more computational operations than there are atoms in the observable universe. AES-256 is used by the US government to protect classified information, and it underpins the encryption in HTTPS connections, VPNs, disk encryption tools like BitLocker and FileVault, and messaging applications worldwide.
The performance advantage of symmetric encryption over asymmetric encryption is significant. Symmetric algorithms like AES run orders of magnitude faster than asymmetric alternatives — a single modern CPU core can encrypt gigabytes of data per second using AES hardware acceleration, while asymmetric operations are thousands of times slower. This speed difference is why real-world systems almost never use asymmetric encryption to encrypt large amounts of data directly. Instead, they use a hybrid approach: asymmetric encryption to securely exchange a symmetric key, and then symmetric encryption (AES) to encrypt the actual data using that key. Every HTTPS connection you make uses exactly this hybrid model.
The fundamental weakness of symmetric encryption is the key distribution problem. If Alice wants to send encrypted data to Bob, they both need the same secret key — but how do they agree on that key without an attacker intercepting it? Sending the key over an insecure channel defeats the purpose of encryption. This problem drove the development of asymmetric encryption and the key exchange protocols that made secure internet communication practical.
Asymmetric Encryption: The Public Key Revolution
Asymmetric encryption — also called public-key cryptography — solved the key distribution problem that limited symmetric encryption. Introduced by Whitfield Diffie and Martin Hellman in their 1976 paper “New Directions in Cryptography,” it replaced the requirement for a shared secret key with a mathematically linked key pair: a public key that anyone can know and use to encrypt data, and a private key that only the owner holds and uses to decrypt it.
The mathematical relationship between the two keys is the foundation of asymmetric security. It relies on problems that are computationally easy to perform in one direction but computationally infeasible to reverse. RSA, the most widely used asymmetric algorithm, is based on the difficulty of factoring very large numbers into their prime factors. Multiplying two 2048-bit prime numbers together takes microseconds; factoring the result back into its two prime components — without knowing what those primes were — would take modern computers longer than the age of the universe at current computational speeds. The public key is derived from that large number; the private key is the pair of primes that produced it.
Elliptic Curve Cryptography (ECC) is the more modern asymmetric approach, providing equivalent security to RSA with dramatically smaller key sizes. An ECC key of 256 bits provides security roughly comparable to a 3072-bit RSA key, which translates directly into faster operations and smaller certificates. This is why modern TLS certificates for HTTPS websites increasingly use ECC, and why the algorithms selected for post-quantum standards include lattice-based alternatives to both.
The Diffie-Hellman key exchange protocol built on the asymmetric concept to solve the key distribution problem directly. Two parties — call them Alice and Bob — can use Diffie-Hellman to agree on a shared secret over a completely public, untrusted channel without ever transmitting that secret. The mathematical mechanism relies on the discrete logarithm problem, and the resulting shared secret can then be used as a symmetric key for AES encryption. Every time you connect to an HTTPS website, your browser and the server perform a variant of this key exchange — typically Elliptic Curve Diffie-Hellman (ECDH) — to establish a shared session key in milliseconds before any sensitive data is transmitted.
Cryptographic Hashing: One-Way Transformation for Integrity
Hashing is the third fundamental mechanism of cryptography, and it is the one most frequently misunderstood — particularly in how it differs from encryption. A cryptographic hash function takes an input of any size and produces a fixed-length output called a hash, digest, or checksum. The critical properties that make a hash function cryptographically useful are that the output is deterministic (the same input always produces the same hash), that it is one-way (you cannot reverse a hash to recover the original input), and that it is collision-resistant (it should be computationally infeasible to find two different inputs that produce the same hash output).
This one-way property is the key difference between hashing and encryption. Encryption is reversible with the correct key — that is its purpose. Hashing is irreversible by design — that is its purpose. The two serve completely different security functions. Encryption protects confidentiality. Hashing protects integrity and enables secure password storage.
SHA-2 and SHA-3 are the current standard hash functions, produced by NIST. SHA-256 (producing a 256-bit hash) and SHA-512 (producing a 512-bit hash) are the most widely used SHA-2 variants. An HTTPS website’s certificate includes a SHA-256 hash of its contents; your browser recalculates that hash and compares it to the signed value to detect any tampering. When you download software, the publisher provides a SHA-256 or SHA-512 hash of the file; recalculating the hash of your downloaded copy and comparing it to the published value confirms the file was not corrupted or modified in transit.
Password storage is where hashing is most commonly misapplied. Storing passwords as plain text is obviously wrong — a database breach exposes every password immediately. Storing encrypted passwords is also wrong — anyone with the encryption key can recover all passwords. Storing hashed passwords using a general-purpose hash like SHA-256 is still wrong, because SHA-256 is designed to be fast, and fast hashing enables attackers to test billions of password guesses per second against stolen hashes (a brute-force or dictionary attack). The correct approach is purpose-built password hashing algorithms — bcrypt, scrypt, or Argon2 — which are deliberately slow and computationally expensive, making brute-force attacks impractically slow even with significant hardware. The “encryption and hashing difference” is not just technical — it determines whether a breach exposes user passwords.
Salting addresses a specific attack called rainbow table attacks, in which an attacker precomputes hashes for millions of common passwords and stores them in a lookup table. A salt is a unique random value appended to each password before hashing, so two users with the same password produce completely different hashes. Salting invalidates rainbow tables entirely. Modern password hashing algorithms like bcrypt and Argon2 handle salting automatically.
Digital Signatures: Authenticity and Non-Repudiation
A digital signature is a cryptographic mechanism that proves a message or document was created by a specific private key holder and has not been modified since being signed. It provides two security properties that neither encryption nor hashing alone delivers: authentication (the signature proves who signed it) and non-repudiation (the signer cannot later deny having signed it).
The mechanics reverse the typical use of asymmetric key pairs. Where encryption uses the recipient’s public key to encrypt and their private key to decrypt, signing uses the signer’s private key to sign and their public key to verify. Alice signs a document by computing a hash of the document and then encrypting that hash with her private key — the result is the digital signature. Bob receives the document and the signature, decrypts the signature using Alice’s public key to recover the hash, independently computes the hash of the received document, and compares the two. If they match, the signature is valid: the document was signed by whoever holds Alice’s private key, and the document has not been modified since signing. If even a single bit of the document changed after signing, the hashes will not match and the signature will be invalid.
Code signing certificates — used to verify that software installers are genuine — are one of the most consequential real-world applications of digital signatures. When you download a Windows application and Windows shows a publisher name with a verified signature, that signature was produced by the software developer’s private key and verified against a certificate issued by a Certificate Authority. Without code signing, there is no reliable way to distinguish a genuine installer from a malicious one that has been modified to include malware.
Email digital signatures via S/MIME or PGP allow recipients to verify that an email actually came from the claimed sender and has not been modified in transit. This is the cryptographic solution to the Business Email Compromise attacks discussed in the previous article in this series — an email signed with the CFO’s private key cannot be convincingly spoofed by an attacker who does not have that private key. The practical adoption of email signing has been slower than its technical availability would suggest, which partially explains why BEC attacks remain so prevalent.
Public Key Infrastructure: The Trust Chain Behind HTTPS
Public key cryptography solves the encryption and signature problems but creates a new one: how do you know that a public key actually belongs to who it claims to belong to? If you want to encrypt a message to Alice using her public key, how do you know you have the real Alice’s public key rather than an attacker’s key who is pretending to be Alice? This is the key authentication problem, and Public Key Infrastructure (PKI) is the system that solves it.
PKI is a hierarchy of trust. At the top are a small number of Certificate Authorities (CAs) — organisations like DigiCert, Sectigo, Let’s Encrypt, and a handful of others whose root certificates are pre-installed in every operating system and browser. These root CAs and intermediate CAs they authorise issue digital certificates that bind a public key to an identity. A certificate for networkustad.com contains the site’s public key, information about the site owner, the issuing CA’s identity, a validity period, and most importantly, a digital signature from the issuing CA over all of this information.
When your browser connects to an HTTPS website, it receives the site’s certificate. The browser verifies the CA’s signature on the certificate (using the CA’s public key from its pre-installed root store), checks that the certificate has not expired, checks that the domain name in the certificate matches the domain you requested, and checks that the certificate has not been revoked (using Certificate Revocation Lists or the Online Certificate Status Protocol). If all checks pass, the browser considers the connection trustworthy. The green padlock in your browser’s address bar represents this entire chain of cryptographic verification happening in milliseconds, invisible to the user.
Certificate Transparency (CT) logs, introduced in 2013 and now required for all publicly trusted certificates, address a specific PKI weakness: a rogue or compromised CA could issue a fraudulent certificate for any domain without the domain owner’s knowledge. CT logs are publicly verifiable append-only records of every certificate issued. Browser vendors and domain owners monitor these logs for unexpected certificates, enabling rapid detection of misissuance. The entire certificate for every HTTPS website you visit has been logged in one of these public CT logs — you can verify this using tools like crt.sh.
Let’s Encrypt, a non-profit CA launched in 2016, deserves specific mention for democratising HTTPS. Before Let’s Encrypt, obtaining a TLS certificate for a website cost money, required manual processes, and took days. Let’s Encrypt made certificate issuance free, automated, and available in minutes — a change that contributed to HTTPS adoption rising from approximately 40% of web traffic in 2016 to over 95% today. The cryptographic underpinning — domain validation, certificate issuance, and renewal — all happens automatically via the ACME protocol.
Encryption in Transit vs Encryption at Rest
A complete understanding of how encryption protects data requires distinguishing between two different threat scenarios: data being intercepted while moving between systems, and data being accessed while stored somewhere. These two scenarios require different cryptographic mechanisms, and defending against one does not automatically defend against the other.
Encryption in transit — also called data-in-motion encryption — protects data as it travels across networks. TLS (Transport Layer Security) is the protocol that provides encryption in transit for the vast majority of internet communications. When you connect to an HTTPS website, the TLS handshake establishes a secure channel using the public key infrastructure described above, performs a key exchange to establish a shared symmetric key, and then encrypts all subsequent traffic using AES. TLS 1.3, the current version, removed several legacy cipher suites and handshake options that were found to be weak, and mandated Perfect Forward Secrecy — a property that ensures that even if a server’s private key is compromised in the future, historical recorded traffic cannot be decrypted. Every HTTPS connection, every secure API call, every VPN tunnel uses some form of TLS or a protocol built on the same principles.
Encryption at rest — also called data-in-storage encryption — protects data stored on disks, in databases, and in cloud storage from being accessed by unauthorised parties who gain physical or logical access to the storage medium. Full-disk encryption tools — BitLocker on Windows, FileVault on macOS, LUKS on Linux — encrypt every sector of a storage device using AES. If a laptop with BitLocker enabled is lost or stolen, the data on the drive is completely inaccessible without the encryption key, which is derived from the user’s PIN or password. Database-level encryption protects specific columns or entire databases from being read by anyone with access to the underlying storage without the application-level keys. Cloud storage providers including AWS S3, Google Cloud Storage, and Azure Blob Storage offer server-side encryption at rest using AES-256, either with provider-managed keys or customer-managed keys in their respective key management services.
The distinction matters practically. An organisation that implements TLS for all API traffic but stores data unencrypted at rest protects against network interception but not against a storage breach. An organisation that encrypts data at rest but transmits it over unencrypted connections protects against storage theft but not against network eavesdropping. Comprehensive data protection requires both.
End-to-End Encryption: Why It Matters for Privacy
End-to-end encryption (E2EE) is a specific property of communication systems in which only the two communicating parties can read the messages — not the service provider carrying them, not network operators, and not government agencies (without access to one endpoint). In a system with E2EE, the encryption and decryption happen only on the users’ devices, and the service provider’s servers see only encrypted ciphertext.
WhatsApp, Signal, iMessage, and FaceTime all implement end-to-end encryption. Signal uses the Signal Protocol — a combination of the Double Ratchet Algorithm for forward secrecy and the X3DH (Extended Triple Diffie-Hellman) key agreement protocol, which provides both forward secrecy (past messages cannot be decrypted if current keys are compromised) and break-in recovery (future messages become secure again even if current keys are compromised). The Signal Protocol has been adopted by WhatsApp, Google Messages, and several other messaging platforms. What encryption does Signal use? The Signal Protocol is the definitive answer — and it is widely considered the strongest practical implementation of E2EE messaging available to consumers.
The legal and political controversy around E2EE stems from law enforcement’s argument that it prevents lawful access to criminal communications. Cryptographers and security researchers consistently counter that any technical mechanism for lawful access — a “backdoor” — necessarily weakens security for all users and would be exploited by criminal actors and nation-state attackers as well as by the intended law enforcement agencies. The cryptographic community has not found a method to provide lawful access that does not fundamentally compromise E2EE’s security guarantees, and the debate continues.
Post-Quantum Cryptography: The Next Frontier
Quantum computers represent the most significant long-term threat to current cryptographic systems. The algorithms that underpin most of today’s asymmetric cryptography — RSA, Elliptic Curve Cryptography, and Diffie-Hellman — derive their security from mathematical problems that classical computers find computationally infeasible: integer factoring, discrete logarithm computation, and elliptic curve discrete logarithm computation. A sufficiently powerful quantum computer running Shor’s algorithm could solve these problems in polynomial time, rendering RSA and ECC insecure.
Symmetric encryption is more resilient. Grover’s algorithm provides a quantum speedup for brute-force key search, halving the effective security of symmetric keys — meaning AES-128 would provide approximately the security of a 64-bit classical key, and AES-256 would retain approximately 128-bit security. The practical implication is that AES-256 and SHA-384 or SHA-512 are considered quantum-safe for symmetric operations, while RSA and ECC key exchange and signatures are not.
NIST released three finalised post-quantum cryptographic standards in August 2024, concluding an eight-year evaluation process. The three standards are FIPS 203 (ML-KEM — Module-Lattice-Based Key Encapsulation Mechanism, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA — Module-Lattice-Based Digital Signature Algorithm, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA — Stateless Hash-Based Digital Signature Algorithm, based on SPHINCS+). ML-KEM replaces RSA and ECDH for key exchange; ML-DSA and SLH-DSA replace ECDSA and RSA for digital signatures. A fourth algorithm, FN-DSA (based on FALCON), is in final stages of standardisation. NIST also selected HQC for standardisation in 2025 as an additional key encapsulation mechanism.
The “harvest now, decrypt later” attack is the most immediate practical concern from quantum computing — even before quantum computers capable of breaking RSA exist, nation-state adversaries are recording encrypted internet traffic today with the intent to decrypt it once quantum computers become powerful enough. Data that needs to remain confidential for ten or more years — classified government communications, long-term business secrets, medical records — is already at risk from this strategy. NIST plans to deprecate all quantum-vulnerable algorithms by 2035, and organisations should begin migration planning now. Post-quantum migration is not a distant concern; it is an active programme that security teams in critical infrastructure, financial services, and government are already implementing.
How Cryptography Works Together in Real Life
Understanding individual cryptographic mechanisms is useful, but the real insight comes from seeing how symmetric encryption, asymmetric encryption, hashing, digital signatures, and PKI work together in the systems you use every day. Every component addresses a specific weakness that the others leave exposed, and the combination provides comprehensive security.
Consider a single HTTPS page load. Your browser begins a TLS 1.3 handshake with the web server. The server presents its certificate — a document containing its public key, signed by a Certificate Authority. Your browser verifies the CA’s digital signature on the certificate using the CA’s public key from its root store, confirms the certificate is valid and not revoked, and confirms the domain name matches. Both sides then perform an ECDH key exchange to agree on a shared symmetric key without transmitting that key over the network. All subsequent communication — the HTTP request, the HTML response, any cookies, any form data — is encrypted with AES using that shared key and authenticated with HMAC to detect tampering. The entire process takes under 100 milliseconds and involves symmetric encryption (AES), asymmetric encryption (ECDH for key exchange), hashing (SHA-256 for certificate integrity), and digital signatures (the CA’s signature on the certificate). Removing any single component would break the system’s security.
Password storage in a well-implemented system adds another layer. When you create an account, your password is not stored — instead, the system generates a random salt, appends it to your password, and runs the combined string through bcrypt or Argon2. Only the salt and the resulting hash are stored. When you log in, the system retrieves your salt, runs the same hash function on your submitted password plus that salt, and compares the result to the stored hash. Your plaintext password never touches the database and cannot be recovered even if the database is stolen. This is why “forgot password” on secure services sends a reset link rather than emailing you your password — the service does not know your password.
WhatsApp’s end-to-end encryption adds yet another layer. Before you send a message, WhatsApp generates a shared encryption key specific to your conversation using X3DH key agreement and your contact’s identity key. The message is encrypted on your device, transmitted as ciphertext through WhatsApp’s servers, and decrypted only on your contact’s device. WhatsApp’s servers see only the ciphertext and cannot read your messages even if compelled by a court order — the keys exist only on the endpoints. This is end-to-end encryption working as designed.
Cryptographic Attacks: What Actually Breaks Encryption
Understanding how cryptography can fail is as important as understanding how it works. The headlines about “encryption being hacked” almost never mean that AES-256 or RSA-2048 has been mathematically broken. What they typically mean is that an implementation was flawed, a key was stolen, a protocol was misconfigured, or a weaker legacy algorithm was still in use.
The Heartbleed vulnerability in 2014 — which affected OpenSSL, the most widely used implementation of TLS — is one of the most illustrative examples. Heartbleed was not a flaw in the cryptographic algorithms themselves; it was a buffer over-read bug in the heartbeat extension implementation that allowed attackers to extract up to 64 kilobytes of memory from the server per request, potentially including private keys. The cryptography was sound; the code implementing it was not. Over 70% of encryption vulnerabilities stem from implementation flaws rather than weaknesses in the underlying cryptographic algorithms. This is why open-source cryptographic libraries like OpenSSL, BoringSSL, and libsodium undergo constant security review, and why the advice to never implement your own cryptographic algorithms from scratch remains one of the most consistently repeated principles in security engineering.
Downgrade attacks exploit the TLS protocol’s support for negotiating the version and cipher suite to use. If a server supports both TLS 1.3 and older, weaker versions for backward compatibility, an attacker positioned as a man-in-the-middle can interfere with the negotiation to force the connection to use a weaker cipher suite. POODLE (2014) and BEAST (2011) were practical downgrade attacks against TLS. The solution is disabling legacy protocol versions entirely — TLS 1.0 and 1.1 are now deprecated and should not be accepted by any server, and TLS 1.2 should enforce strong cipher suites only.
Brute-force key attacks — systematically trying every possible key until the correct one is found — are the theoretical attack against symmetric encryption. The reason AES-128 is considered secure is that there are 2^128 possible 128-bit keys, and trying all of them at any realistic computational rate would take longer than the age of the universe. AES-256 with its 2^256 keyspace provides a margin so large it is essentially unconditional with classical computers. The quantum speedup from Grover’s algorithm halves the effective keyspace exponent (AES-128 becomes equivalent to 64-bit security under quantum attack), which is why AES-256 is preferred for long-term security. But “can encrypted data be hacked” in the sense of breaking AES-256 by brute force? No — not with any technology that exists or is foreseeable with classical computing.
Conclusion
Cryptography is the invisible infrastructure that makes digital trust possible. Every secure website, every encrypted message, every verified software download, and every authenticated digital transaction depends on the mathematical mechanisms covered in this guide. Symmetric encryption (AES) protects the confidentiality of data efficiently. Asymmetric encryption (RSA, ECC) solves the key distribution problem and enables digital signatures. Hashing (SHA-2, bcrypt) verifies integrity and enables secure password storage. PKI creates a chain of trust that allows strangers across the internet to communicate securely. And post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) are being deployed now to protect against the quantum computing threats that will challenge current asymmetric algorithms in the coming decade.
The practical takeaway for security practitioners is that cryptography is not a single tool but an ecosystem of mechanisms, each addressing a specific threat. Implementation quality matters more than algorithm selection in most real-world breaches — the correct algorithms (AES-256, SHA-256, TLS 1.3, ECDH) are well-established, but deploying them correctly, keeping them updated, and managing keys securely are where security programmes succeed or fail. NIST’s 2035 deadline for migrating away from quantum-vulnerable algorithms is already driving post-quantum migration programmes in critical infrastructure, financial services, and government. For everyone else, the time to begin assessing quantum exposure in long-lived systems is now.
For those pursuing the CISSP certification, cryptography is covered primarily in Domain 3 (Security Architecture and Engineering) and overlaps with Domain 4 (Communication and Network Security) for protocols like TLS, Domain 5 (Identity and Access Management) for PKI and certificate-based authentication, and Domain 8 (Software Development Security) for secure code implementation. The eight CISSP domains and their coverage are detailed in our complete CISSP domains guide.
Next Article Preview:
In the next article, we will explore “Network Security Fundamentals: Firewalls, IDS/IPS, and Zero Trust Architecture” — how the cryptographic protocols covered in this guide are enforced at the network level, and how modern Zero Trust frameworks replace perimeter-based security models.
Sources: NIST Post-Quantum Cryptography Standards announcement, August 2024, NIST FIPS 203 ML-KEM, NIST FIPS 204 ML-DSA, NIST FIPS 205 SLH-DSA. TLS 1.3 specification from RFC 8446. Implementation vulnerability statistics from Training Camp Encryption Best Practices 2025. Post-quantum market projections from DEV.to Data Encryption Complete 2026 Guide. Signal Protocol documentation from Signal.org Technical Documentation. Certificate Transparency from certificate.transparency.dev. Prices and deprecation timeline from NIST Post-Quantum FAQ — July 2026
