Why Cryptography Exists in Software Systems

A Story: The Courier

Imagine you are a merchant in ancient times. You have a trading partner in a distant city. You need to send important messages — prices, inventory, shipping dates. But the road between your cities is dangerous. There are bandits. There are rival merchants who would love to know your prices. There are people who might change your messages to harm your business.

You hire a courier. You write your message on parchment, fold it, and seal it with wax. The courier rides off.

You worry. What if the courier is intercepted? What if someone reads your message? What if someone opens it, changes the price, and reseals it with fake wax? How do you know the message you receive from your partner is really from them, and not a forgery?

This is the problem cryptography solves.

The road is the internet. The courier is the network. The bandits are attackers. The wax seal is a digital signature. The locked box is encryption, and only your partner has the key.

Cryptography does not make the road safe. It makes the message safe even when the road is not.

This article explains why cryptography exists in software systems. It is not about the mathematics of cryptography — that comes in later articles. It is about the problems cryptography solves and the security goals it enables. Understanding these goals is essential before you learn how to implement them.

The Fundamental Problem: Trust Over Untrusted Networks

Every day, your applications send data across networks you do not control. A user in London sends a password to your server in Virginia. The packet travels through dozens of routers, switches, and fiber-optic cables, passing through networks owned by internet service providers, cloud providers, and undersea cable operators. Any one of these could be compromised.

The fundamental problem of network security is this: how do you establish trust between two parties that have never met, communicating over a medium you cannot control?

Cryptography is the answer. It allows two parties to communicate privately even when others can see the communication, verify identity even when they have never met, detect tampering even when others can modify the communication, and prove authenticity so the recipient knows who sent the message.

Before cryptography, secure communication required physical security. You put the message in a locked box and sent a trusted courier. You met in person to exchange secrets. You trusted the physical integrity of the channel. Today, cryptography replaces physical security with mathematical security. Instead of assuming the courier is trustworthy, you assume that certain mathematical problems are hard to solve. Instead of assuming the channel is secure, you assume that encryption cannot be broken without the key.

The Four Security Goals

Every security system aims to achieve four core properties. These goals define what "secure" actually means in practice.

Confidentiality

Confidentiality means that information is not disclosed to unauthorized parties. When you send a message over the network, only the intended recipient should be able to read it. When you store data in a database, only authorized users should be able to access it. Confidentiality is what most people think of first when they think about security — keeping secrets secret.

Cryptography provides confidentiality through encryption. Encryption transforms readable data (plaintext) into unreadable data (ciphertext). Only someone with the correct decryption key can reverse the transformation, so even if an attacker intercepts the encrypted data, they cannot read it. HTTPS encrypts web traffic so your password is not visible to others on the network. Encrypted databases protect customer data if storage is breached. Encrypted emails prevent unauthorized reading in transit.

Integrity

Imagine you send a letter to a friend. On the way, someone opens the envelope, changes a word, and reseals it. When your friend gets the letter, they have no idea it was changed. The message they read is not what you wrote.

Integrity is about knowing that your data has not been changed — by accident or on purpose.

When you send data over the internet, it passes through many computers you do not control. Any one of them could modify your data. Integrity guarantees that the recipient can tell if the data was altered.

How cryptography protects integrity:

1. Hash functions work like a fingerprint for your data. You run your message through a hash function, and it produces a short, unique string. If even a single letter changes, the fingerprint changes completely. The recipient runs the same hash function and compares fingerprints. If they match, the message is unchanged.
2. Message Authentication Codes (MACs) add a secret key to the hash. Only someone with the key can create the correct fingerprint. This proves not only that the data is unchanged, but that it came from someone who has the key.

Real-world examples you have seen:

Software downloads. When you download a program from the internet, the website sometimes shows a long string of letters and numbers called a checksum. After you download the file, you can run a program that calculates the checksum of the file you received. If it matches the one on the website, you know the file downloaded correctly and was not tampered with by anyone.

Secure websites (HTTPS). When you visit a website with a padlock icon in your browser, that padlock means the connection is encrypted. But it also means something else: your browser has verified that the website's certificate is valid. This verification ensures that the website you are talking to is actually the real website, not a fake one pretending to be it. No one on the network can secretly swap out the real website for a fake one.

QR codes. When you scan a QR code on a boarding pass or event ticket, the code contains data that has a built-in checksum. If someone tries to modify the QR code by hand — changing a number — the checksum will no longer match, and the scanner will reject it. This prevents people from tampering with tickets.

Availability

Availability means that information and systems are accessible when needed. Unlike confidentiality and integrity, availability is not directly provided by cryptography — and it deserves a note of honesty here. Cryptography can sometimes harm availability: encryption keys can be lost, certificates can expire, and poorly designed systems can become inaccessible when cryptographic components fail. Availability is the third leg of the classic CIA triad, but it stands apart from the other two in its mechanisms.

Good system design manages this tension through redundant key storage, so that a lost key does not lock users out permanently, and through resilient architectures that ensure failure of one component does not bring down the whole system. Availability is ultimately a design and operations concern as much as a security one.

Authenticity

Authenticity means that the identity of the sender or source can be verified. Confidentiality and integrity are not enough on their own. You also need to know who sent the message. Is this email really from your bank? Is this software update really from the vendor? Is this user really who they claim to be?

Cryptography provides authenticity through digital signatures and authentication protocols. A digital signature allows a sender to sign a message with their private key; anyone with the corresponding public key can verify the signature and confirm that the message came from the holder of that key, and has not been altered since signing. In practice, TLS certificates verify that the website you are connecting to is who it claims to be. Code-signing certificates prove that software comes from the stated publisher. JWT signatures prove that a token was issued by a trusted authorization server.

A closely related property worth knowing is non-repudiation: the sender cannot later deny having sent a signed message, because only their private key could have produced the signature. This matters in legal and audit contexts, where proving that a specific party took a specific action may be essential.

Why Cryptography Exists: Historical Failures

Cryptography did not emerge from abstract mathematics. It emerged from real failures. Understanding those failures helps you appreciate why cryptography is not optional.

The Failure of Physical Security

Before the internet, physical security was the primary protection. Data was kept in locked rooms. Couriers carried messages. You trusted the physical integrity of the channel. The internet eliminated that assumption entirely. A packet from London to Virginia passes through dozens of networks you have no control over. You cannot lock the road. Cryptography replaced the locked room and the trusted courier with mathematical guarantees.

The Failure of Security Through Obscurity

Early systems often relied on hiding how they worked, hoping attackers would not figure them out. The original encryption used in GSM mobile networks was kept secret. When it was eventually reverse-engineered, it was found to be weak, and attackers had been exploiting it for years without anyone who could fix it even knowing.

The lesson: security through obscurity does not work. Cryptographic algorithms are public — the security comes from the keys, not from secrecy about the algorithm itself. This principle, known as Kerckhoffs's principle, has been a cornerstone of cryptographic design for over a century.

The Failure of Unauthenticated Communication

Early internet protocols sent everything in plaintext. Email, FTP, Telnet — all unencrypted, all wide open. Attackers could capture credentials, read messages, and modify data in transit without detection. Without encryption and authentication, the network is a public square. Anyone can listen, capture, and impersonate.

The Failure of Password-Only Authentication

Early systems relied solely on passwords. Passwords were often sent over the network in plaintext, stored in databases without hashing, and reused across services. The 2012 LinkedIn breach ultimately exposed around 117 million password records. Many were stored without proper hashing, and the credentials were subsequently used to compromise other services where users had reused the same passwords.

Passwords alone are not enough because if someone steals your password, they can pretend to be you. But there is another problem: companies need to store your password safely. When they store it, they should never keep it as plain text — that would be like writing your combination on a sticky note stuck to the lockbox. Instead, they use a hash, which is like running your password through a blender. Out comes a jumbled mess that cannot be turned back into the original password. The same password always produces the same jumbled mess, so when you log in, the website runs what you type through the same blender and compares the result. To make things even safer, they add a random salt (a unique random value) to each password before blending it. This way, even if two people use the same password, their hashes look completely different. So when you hear "never store passwords in plain text," this is what it means — always store salted hashes so stolen databases are useless to attackers.

The Cryptographic Toolbox

Cryptography provides a set of tools, each designed to address specific security goals. Later articles cover each in depth. Here is the toolbox at a glance.

Symmetric encryption uses the same key to encrypt and decrypt. It is fast and efficient, making it suitable for encrypting large volumes of data — databases, files, disk volumes, and the bulk data flowing through a TLS session after the handshake. Its challenge is key distribution: how do two parties that have never met securely share a key?

Asymmetric encryption uses a key pair — a public key and a private key. Data encrypted with the public key can only be decrypted with the private key. This solves the key distribution problem: you can publish your public key for anyone to use, while keeping the private key secret. Asymmetric encryption is slower than symmetric encryption, so in practice it is typically used for key exchange and digital signatures rather than bulk data encryption.

Hash functions take an input of any size and produce a fixed-size output (the hash or digest). The same input always produces the same output, but any change to the input produces a completely different output. The process is one-way — you cannot derive the input from the output. Hash functions underpin password storage, integrity verification, and digital signatures.

Message Authentication Codes (MACs) combine a secret key with a message to produce a tag. Anyone with the secret key can verify the tag, proving that the message was not tampered with and came from someone who holds the key. HMACs (hash-based MACs) are widely used for API request signing and session token integrity.

Digital signatures combine asymmetric cryptography with hashing. To sign a message, the sender computes a hash of the message and encrypts that hash with their private key. Anyone with the corresponding public key can verify the signature: they decrypt it to recover the hash, then compute the hash of the message themselves to confirm they match. This is important — the signature is applied to the hash of the message, not to the message content directly. Digital signatures are used in JWTs, code signing, TLS certificates, and document signing.

How Cryptography Enables Trust at Scale

Trust is the currency of digital systems. Cryptography is how you mint it without requiring everyone to meet in person.

Without cryptography, trust requires physical control of the channel, personal relationships with the parties involved, or trusted couriers. None of these scale to the internet. You cannot have a private cable to every website. You do not personally know the operators of every service you use. You cannot vet every network operator.

With cryptography, trust is established through mathematical proofs (certain operations are computationally infeasible to reverse without the key), verifiable identities (digital certificates provide a chain of trust from a recognized authority), and shared secrets established securely between strangers (key exchange protocols like Diffie-Hellman allow two parties to agree on a secret over a public channel).

The trust model in TLS illustrates this concretely. Your browser ships with a pre-installed set of trusted Certificate Authorities (CAs). When you visit a website, the site presents a certificate signed by a CA. Your browser verifies the CA's signature, confirms the certificate belongs to the domain you requested, and establishes an encrypted session — all within milliseconds, without any prior relationship between you and the website operator. You trust the CA to have verified the website's identity, and you trust that the CA's private key has not been compromised. That chain of trust scales to the entire web.

Cryptography and the Unbroken Chain

Security in a layered system depends on every layer holding. Cryptography is the thread that runs through all of them.

In the browser layer, TLS uses cryptography to establish a secure channel, verify the server's identity, and encrypt all traffic. In the authentication layer, password hashing ensures that even if a database is breached, plaintext passwords are not exposed; tokens are signed with cryptographic keys to prevent tampering. In the authorization layer, JWTs carry signed claims that resource servers can verify without contacting the issuer on every request. In the infrastructure layer, mutual TLS (mTLS) encrypts and authenticates service-to-service communication; VPNs and encrypted tunnels protect network traffic between systems. In the data layer, encryption at rest protects data stored on disk, and encryption in transit protects it while moving across networks.

Without cryptography, every one of these links is vulnerable to interception, tampering, and impersonation. Cryptography is what makes the chain resilient.

The Limits of Cryptography

Cryptography is powerful, but it is not magic. Knowing its limits is just as important as knowing its capabilities.

Cryptography does not fix broken design. You can encrypt all your data and still have a broken access control system that lets users see each other's records. Cryptography protects data in transit and at rest. It does not fix authorization failures.

Cryptography does not protect against stolen keys. If an attacker obtains the encryption key, the encryption is worthless. Key management is consistently one of the weakest links in real-world systems. Storing keys in the same location as the encrypted data defeats the entire purpose.

Cryptography does not stop social engineering. An attacker who convinces a user to hand over their password, or to approve a fraudulent authentication request, bypasses all cryptographic protections. The strongest encryption in the world cannot protect against a person being tricked.

Cryptography does not stop insider threats. An employee with legitimate access can abuse that access. Cryptography does not prevent authorized users from doing unauthorized things — that requires monitoring, auditing, and governance.

Cryptography does not guarantee availability. Lost keys can make data permanently inaccessible. Expired certificates take websites offline. Cryptographic complexity, if poorly managed, creates fragility. Resilience requires deliberate operational discipline.

All cryptography rests on an assumption. The security of every cryptographic system depends on certain mathematical problems being computationally hard to solve — factoring large numbers, computing discrete logarithms, finding hash collisions. We have strong evidence these problems are hard, but not mathematical proof. Quantum computing poses a real threat to some of these assumptions, particularly those underlying RSA and elliptic-curve cryptography. The field of post-quantum cryptography is actively developing replacements, and this is an active area of standardization. When choosing algorithms today, it is worth understanding which ones have post-quantum candidates and which do not.

Why Developers Must Understand Cryptography

You do not need to be a cryptographer to write secure software. But you do need to understand what cryptography does and does not provide.

Understand the goals. Know whether you need confidentiality, integrity, authenticity, or some combination. Know which cryptographic tools provide which guarantees, and what they leave unaddressed.

Use established tools. Never implement your own cryptographic primitives. Use well-maintained libraries and protocols. The cryptography you invent will be weaker than the cryptography built and reviewed by specialists over decades.

Manage keys as a first-class concern. The strongest encryption is useless if the keys are stored alongside the data they protect, or committed to source control, or hardcoded in configuration files. Key management is often the hardest part of applied cryptography.

Stay current. Algorithms weaken over time as attacks improve. MD5 and SHA-1 are broken for security purposes. Older RSA key sizes that were once acceptable are now too small. For symmetric encryption, AES-256 is generally preferred over AES-128, particularly given emerging concerns about quantum computing. The algorithms that are secure today may be insecure in a decade. Know what you are using and track whether it remains recommended.

What You Should Take Away

After reading this article, you should understand that cryptography exists to solve a fundamental problem: establishing trust between parties communicating over networks they do not control.

You should be able to explain the four core security goals — confidentiality, integrity, availability, and authenticity — and describe what cryptography does and does not provide for each. You should understand why cryptography became necessary, through the historical failures of physical security, security through obscurity, unauthenticated communication, and password-only authentication. You should be able to describe the cryptographic toolbox at a high level — symmetric encryption, asymmetric encryption, hash functions, MACs, and digital signatures — and name the primary use case for each. And you should recognize the limits of cryptography: it does not fix broken design, protect against stolen keys, prevent social engineering, or stop insiders with legitimate access.

Most importantly, you should understand that cryptography is not about making systems impenetrable. It is about making systems resilient. It is about ensuring that even when attackers intercept traffic, they cannot read it. Even when they modify messages, they cannot fool the recipient. Even when they breach the database, they cannot recover the passwords.

Cryptography is the foundation of digital trust. Everything else in this series builds on it.

Closing: The Courier Revisited

Let us return to the courier.

You are a merchant. Your trading partner is across dangerous roads. You need to send messages you can trust.

You put your message in a locked box. Only your partner has the key. Even if the box is intercepted, the contents remain secret. That is confidentiality.

You seal the box with an unforgeable wax pattern. If the seal is broken, you know the box was opened. If the seal is intact but the pattern is wrong, you know someone made a copy. That is integrity.

You sign the message with a mark only you can make. Your partner recognizes your mark and knows the message came from you — and that you cannot later deny sending it. That is authenticity, and non-repudiation.

The road is still dangerous. Bandits still roam. Couriers can still be intercepted. But your messages are safe. You have not made the road safe. You have made the messages safe even when the road is not.

This is why cryptography exists. It does not fix the network. It does not make attackers disappear. It makes your data secure even in an insecure world.

In the articles that follow, you will learn how.