What Is Encryption: How Data Stays Private

In November 2014, hackers released nearly 100 terabytes of Sony Pictures internal data — emails, salary records, unreleased films, and personal information for thousands of employees. What made the breach particularly damaging was not just that the attackers got in; it was that the sensitive data was stored in a way that made it immediately readable. Security researchers found that Sony had stored passwords in a folder literally named "Password." The data the attackers stole was not protected by any meaningful encryption. Once they had the files, they had everything.

Contrast this with a scenario where the same files had been properly encrypted at rest. The attackers would still have stolen something, but they would have been left with an enormous collection of meaningless ciphertext — computationally indistinguishable from random noise without the decryption keys. The breach would still have happened, but its consequences would have been drastically reduced.

This gap — between what encryption promises and whether organizations actually use it correctly — is where most of the real story of encryption lives. The mathematics of modern cryptography is well-understood and, when properly implemented, effectively unbreakable by any known method. The failures happen at the edges: in key management, in implementation choices, in what gets encrypted and what gets left exposed.

"Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it." — Bruce Schneier

"If privacy is outlawed, only outlaws will have privacy." — Phil Zimmermann

"Encryption is the most important privacy-protecting technology we have, and it works best when it's on by default." — Edward Snowden

"The biggest breakthrough in cryptography of the century was not a new algorithm. It was the realization that you could share a secret without ever sharing it." — Whitfield Diffie

What Encryption Actually Does

Encryption is the process of transforming readable data — called plaintext — into an unreadable format called ciphertext, using a mathematical algorithm and a key. The transformation is deterministic and reversible: the same algorithm run in reverse with the correct key will reproduce the original plaintext exactly.

The key insight is that the security of modern encryption does not depend on keeping the algorithm secret. Algorithms like AES and RSA are fully public, extensively analyzed, and implemented in open-source libraries. What matters is the key. The algorithm is the lock design; the key is the specific key that opens a particular lock. Publishing the lock design does not let anyone open a lock without the right key, provided the lock design is strong enough.

A simple historical example illustrates the concept. Julius Caesar reportedly encrypted messages by shifting each letter a fixed number of positions in the alphabet — shifting by 3 turns "attack" into "dwwdfn." This is a substitution cipher. Anyone who knows the shift value of 3 can decrypt any message. The weakness is that there are only 25 possible shifts, making it trivially breakable by trying each one. Modern encryption operates on the same conceptual principle — transform plaintext using a mathematical rule based on a key — but with algorithms and key spaces of extraordinary complexity.

From Caesar to Modern Cryptography

The history of cryptography runs parallel to the history of warfare and statecraft, because secrets have always mattered to people with power. The Vigenere cipher, developed in the 16th century, used a repeating keyword to vary the substitution, defeating simple frequency analysis. The Enigma machine used by Germany in World War II implemented a sophisticated electromechanical cipher that the Allies at Bletchley Park, including Alan Turing, spent years breaking — a breakthrough that historians estimate shortened the war by two years.

The fundamental limitation of all pre-digital cryptography was what cryptographers call the key distribution problem. If you want to send an encrypted message to someone, you first have to agree on a shared key. But how do you share the key securely? If you could share information securely, you would not need encryption in the first place. This circular problem limited encryption to organizations that could establish shared secrets through secure channels — embassies, military couriers, direct meetings.

The 1976 paper by Whitfield Diffie and Martin Hellman, "New Directions in Cryptography," solved this problem and launched the modern era of cryptography. Their insight was a mathematical process that allows two parties to establish a shared secret key over a completely public channel without ever transmitting the key itself. The mathematics involves modular exponentiation and discrete logarithms — operations that are easy to compute in one direction and computationally infeasible to reverse. Their work made public-key cryptography possible, enabling the encrypted internet we rely on today.

Symmetric Encryption: Speed and the Key Problem

Symmetric encryption uses the same key to encrypt and decrypt data. The sender scrambles the plaintext with the key; the receiver uses the identical key to unscramble the ciphertext. This approach is computationally efficient — modern hardware can encrypt gigabytes of data per second using symmetric algorithms — which makes it suitable for encrypting large volumes of data.

The dominant symmetric encryption standard today is AES, the Advanced Encryption Standard. The United States National Institute of Standards and Technology (NIST) selected AES in 2001 after a five-year public competition that evaluated fifteen candidate algorithms. AES operates on 128-bit blocks of data and supports key sizes of 128, 192, or 256 bits. AES-256 — the version with 256-bit keys — is used for encrypting classified US government communications and is the gold standard for data-at-rest encryption.

To understand what AES-256 security means in practice: there are 2^256 possible keys, a number so large that even a computer performing a trillion operations per second would need longer than the current age of the universe to check them all by brute force. The security of AES is not in doubt. What is in doubt, in practice, is always the implementation — how the key is generated, stored, and managed.

AES-256 is what your iPhone uses to encrypt its storage. It is what encrypts files on a BitLocker-protected Windows drive and a FileVault-protected Mac. It is what Amazon Web Services and Google Cloud use to encrypt data at rest in their storage systems. When you see an organization claim it encrypts your data, AES-256 is almost certainly the algorithm they mean.

The limitation of symmetric encryption is precisely what motivated Diffie and Hellman: to use it, both parties need the same key, and distributing that key securely is a problem. If you use symmetric encryption to protect data you are sending to someone, you have to get the key to them through some other secure channel, which is not always practical.

Asymmetric Encryption: The Public-Private Key Pair

Asymmetric encryption solves the key distribution problem by using two mathematically linked keys: a public key and a private key. Anything encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. The public key can be freely shared — posted on a website, included in an email signature, embedded in a certificate. The private key is kept secret by its owner.

The mathematics underlying most asymmetric systems — most notably RSA, developed by Ron Rivest, Adi Shamir, and Leonard Adleman at MIT in 1977 — relies on the difficulty of factoring large numbers. Multiplying two large prime numbers together is fast; factoring the result back into its prime components is computationally infeasible for numbers of sufficient size. A 2048-bit RSA key, for example, has never been factored and is considered secure for most current applications, though 3072-bit or 4096-bit keys are increasingly recommended for new implementations.

The RSA paper is remarkable partly because Rivest, Shamir, and Adleman initially doubted they had actually solved the problem. As Rivest later described, Shamir had the idea late one night and called him in excitement. They spent weeks trying to find the flaw before accepting that the scheme actually worked.

Asymmetric encryption is slower than symmetric — often 1000 times slower for equivalent data volumes — which is why it is not used to encrypt bulk data directly. Instead, it solves the key exchange problem so that symmetric encryption can be used for the actual data.

Symmetric vs. Asymmetric Encryption: A Comparison

Dimension	Symmetric Encryption	Asymmetric Encryption
Key type	Single shared key (same to encrypt and decrypt)	Key pair: public key to encrypt, private key to decrypt
Speed	Very fast; suitable for large data volumes	Slow; typically 1000x slower than symmetric
Use case	Bulk data encryption (files, databases, disk)	Key exchange, digital signatures, TLS handshakes
Example algorithm	AES-128, AES-256, ChaCha20	RSA-2048, RSA-4096, ECC (ECDH, ECDSA)

How HTTPS Works: The TLS Handshake

Every time you visit a website over HTTPS, your browser and the website's server execute a procedure called the TLS handshake. TLS (Transport Layer Security) is the protocol that provides encrypted communications over the web. Understanding the handshake makes the relationship between symmetric and asymmetric encryption concrete.

The handshake begins with your browser sending a "hello" message that includes the TLS version it supports and a list of cipher suites — combinations of algorithms it knows how to use. The server responds with its own hello, selects a cipher suite from the list, and sends its digital certificate. The certificate contains the server's public key and is signed by a Certificate Authority (CA) — a trusted third party like DigiCert or Let's Encrypt whose signatures browsers are configured to trust.

Your browser verifies the certificate's authenticity by checking the CA's signature. This step prevents man-in-the-middle attacks, where an attacker intercepts traffic and presents their own fake certificate. If the certificate is valid, the browser uses the server's public key to help establish a shared symmetric session key through a process that ensures neither side directly transmits the key. Once both sides have derived this session key, they use AES or another symmetric cipher to encrypt the rest of the conversation.

The result is that the bulk of data — the web page content, your form submissions, your session cookies — travels encrypted with fast symmetric encryption, while the slow asymmetric operations handled only the initial key exchange. The padlock in your browser address bar indicates this process completed successfully.

End-to-End Encryption: What It Actually Means

End-to-end encryption (E2EE) is a specific architecture that extends the protection of encryption to the service provider itself. In a standard HTTPS connection, your data is encrypted in transit, but the server decrypts it when it arrives. Google can read your Gmail messages on its servers. A bank can read your account messages. The server is an endpoint, and data is plaintext there.

End-to-end encryption means the data is encrypted on your device, transmitted and stored as ciphertext, and can only be decrypted on the recipient's device. The service provider whose servers carry the message never has access to the decryption keys and therefore cannot read the content, even if compelled by a court order or compromised by an attacker.

Signal, the messaging application developed by Moxie Marlinspike and Open Whisper Systems, pioneered practical E2EE for consumer messaging. The Signal Protocol that underlies it uses a combination of the Diffie-Hellman key exchange and what cryptographers call a "ratchet" mechanism — a system that generates new encryption keys for each message, so that compromising one message's key does not expose any other messages. WhatsApp adopted the Signal Protocol in 2016, making E2EE the default for its 2 billion users.

E2EE is strong protection, but it is worth being precise about what it protects and what it does not. Signal cannot read your messages; your message content is genuinely private from the provider. But Signal can see metadata: who you messaged, when, and how frequently. Metadata analysis can reveal significant information even without message content. If a government sees that you are in regular encrypted communication with a known activist, journalist, or suspected criminal, that metadata has investigative value regardless of what the messages say.

E2EE also does not protect against endpoint compromise. If malware is installed on your phone, it can read your messages on your screen before they are encrypted. Signal cannot protect you from a compromised device. In the 2019 WhatsApp vulnerability discovered by security researchers at Citizen Lab, attackers could install spyware with a single missed video call — the encryption was intact, but the endpoint was not.

What Encryption Protects Against — and What It Does Not

Encryption provides strong protection against specific threats. It protects data in transit against eavesdropping: anyone who intercepts encrypted packets between you and a web server sees only ciphertext they cannot read. It protects data at rest against theft: a stolen laptop with full-disk encryption is useless to an attacker who does not have the key. It protects stored data against server breaches where the attacker copies the database but does not obtain the keys.

What encryption does not protect: it does nothing against malware operating on a device before encryption happens or after decryption happens. It does not protect against bad passwords, which are one of the most common ways encryption keys are compromised in practice. It does not protect against social engineering that tricks users into revealing credentials. It does not protect against vulnerabilities in the software that implements the encryption — OpenSSL's Heartbleed vulnerability in 2014 allowed attackers to read arbitrary memory from servers running the vulnerable version, effectively bypassing TLS encryption.

The LinkedIn breach of 2012 illustrates what happens when encryption is present but poorly implemented. LinkedIn stored user passwords hashed with SHA-1 without "salting" — a technique of adding random data to each password before hashing to ensure identical passwords produce different hashes. When the database of 6.5 million hashed passwords leaked, attackers used precomputed lookup tables called rainbow tables to reverse millions of hashes quickly. A stronger algorithm (bcrypt, Argon2) and proper salting would have made the hashes computationally infeasible to reverse. The lesson is not that encryption was absent but that the wrong type was used the wrong way.

Key Management: The Hard Part

The security of any encryption system depends on the security of its keys. This is where most real-world encryption failures occur, and it is consistently underestimated by organizations that believe encryption is a checkbox rather than a practice.

Key management encompasses the full lifecycle of cryptographic keys: generation, distribution, storage, rotation, and revocation. Each stage introduces risk if handled carelessly. Keys should be generated with cryptographically secure random number generators — not predictable pseudo-random sources. They should be stored separately from the data they protect — a key stored in the same database as the encrypted data provides little additional protection if the database is compromised. They should be rotated periodically, so that a key compromised without immediate detection limits the window of exposure. They should be revoked and replaced when personnel with access leave an organization or when compromise is suspected.

Cloud providers offer dedicated key management services — AWS Key Management Service, Google Cloud KMS, Azure Key Vault — that handle many of these concerns. Some organizations use hardware security modules (HSMs), tamper-resistant physical devices designed specifically to store and use cryptographic keys without ever exposing the raw key material to software. The payment card industry's HSM requirements exist precisely because of how often software-based key storage leads to compromise.

The gold standard for key protection combines multiple controls: HSM storage, strict access policies, audit logging of every key operation, geographic distribution, and regular key rotation. Most organizations achieve something considerably less than this, and the gap is where attackers find their opportunities.

Encryption at Rest vs. Encryption in Transit

The distinction between encryption in transit and encryption at rest reflects two different threat scenarios and requires two different implementations.

Encryption in transit protects data moving across a network. TLS over HTTPS is the most visible example. Secure Shell (SSH) encrypts administrative connections to servers. Virtual Private Networks (VPNs) encrypt traffic from a device to a network gateway. Any time data travels across infrastructure that is not under your full physical control — which is almost always — encryption in transit is essential.

Encryption at rest protects data that is stored. Full-disk encryption tools like BitLocker on Windows and FileVault on macOS encrypt everything written to the drive, so the drive is meaningless without authentication. Database encryption protects stored records. Object storage services like Amazon S3 and Google Cloud Storage can encrypt every object automatically. Backup encryption ensures that stolen or improperly disposed backup media does not expose data.

Both are necessary. Organizations that encrypt data in transit but not at rest are protected against network interception but exposed to server-side breaches, theft of hardware, and insider threats. Organizations that encrypt at rest but not in transit are protected against storage theft but vulnerable to eavesdropping and interception. A complete security posture requires both, applied consistently across all systems that handle sensitive data.

The Quantum Computing Threat and Post-Quantum Cryptography

The asymmetric encryption algorithms that secure the internet — RSA, elliptic curve cryptography (ECC), and the Diffie-Hellman key exchange — all rely on mathematical problems that are computationally hard for classical computers. RSA's security depends on the difficulty of factoring large numbers. ECC's security depends on the difficulty of the elliptic curve discrete logarithm problem.

In 1994, mathematician Peter Shor published a quantum algorithm that could solve both factoring and discrete logarithm problems in polynomial time on a sufficiently powerful quantum computer — exponentially faster than the best known classical algorithms. If a large-scale, error-corrected quantum computer were built, it would render RSA and ECC insecure with no warning period except the years of research that preceded it.

This threat is real but not immediate. Current quantum computers are small, noisy, and error-prone. Breaking RSA-2048 would require millions of logical qubits with error correction; the largest current systems have hundreds of physical qubits. However, adversaries with the resources to build such computers are already collecting encrypted traffic today, with the intention of decrypting it when quantum computers mature — a strategy called "harvest now, decrypt later." Data that needs to remain secret for decades faces a genuine quantum threat.

NIST completed its post-quantum cryptography standardization process in 2024, selecting four algorithms: CRYSTALS-Kyber for key encapsulation (replacing RSA and ECDH for key exchange) and CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures. These algorithms are based on mathematical problems that are believed to be hard for both classical and quantum computers, primarily the difficulty of solving certain lattice problems.

Major technology companies are beginning to migrate. Google has incorporated post-quantum cryptography into Chrome and its internal infrastructure. Apple announced post-quantum support in iMessage. The migration will take years and requires updating both clients and servers simultaneously — a transition comparable in complexity to the shift from HTTP to HTTPS, which took nearly a decade to become the web's default.

Practical Takeaways

Understanding encryption conceptually is useful only if it informs actual decisions. Several practical principles follow from everything covered above.

The encryption algorithm itself is rarely the problem. AES-256 is secure. TLS 1.3 is well-designed. The Signal Protocol is excellent. What goes wrong is implementation and key management — how these algorithms are deployed, who has access to keys, and how those keys are protected.

Encryption in transit and encryption at rest are both necessary and serve different threat models. An organization that has only one without the other has a gap that attackers will find.

End-to-end encryption provides strong content protection but does not eliminate metadata exposure and does not protect compromised endpoints. Threat modeling should reflect these limits.

The quantum transition is not urgent for most organizations today but is relevant for any data that must remain confidential for decades and for organizations that need to plan multi-year infrastructure migrations.

Good key management is harder than good algorithm selection and matters far more for practical security. The investment in proper key lifecycle management — including hardware security modules for the most sensitive keys, strict access controls, audit logging, and regular rotation — pays higher security dividends than debating algorithm choices among already-strong options.

The Sony Pictures breach and the LinkedIn password failure are instructive not because the organizations were uniquely incompetent but because they reflect a pattern: encryption is technically understood but organizationally deprioritized until after a breach makes the gap visible. The goal of understanding encryption is to make those tradeoffs consciously, before the cost of getting them wrong arrives.

References

1. Diffie, W. & Hellman, M. (1976). "New directions in cryptography." IEEE Transactions on Information Theory, 22(6), 644-654.
2. Schneier, B. (1996). Applied Cryptography: Protocols, Algorithms, and Source Code in C (2nd ed.). Wiley.
3. NIST. (2024). Post-Quantum Cryptography Standards: FIPS 203, 204, and 205. National Institute of Standards and Technology.
4. Ferguson, N., Schneier, B., & Kohno, T. (2010). Cryptography Engineering: Design Principles and Practical Applications. Wiley.
5. Bernstein, D. J. & Lange, T. (2017). "Post-quantum cryptography." Nature, 549(7671), 188-194.
6. Codenomicon. (2014). "The Heartbleed bug." heartbleed.com. Retrieved from heartbleed.com.

Frequently Asked Questions

What is encryption in simple terms?

Encryption is the process of scrambling data using a mathematical algorithm so that it becomes unreadable to anyone who does not have the specific key needed to unscramble it. The original readable data is called plaintext. After encryption it becomes ciphertext, which looks like random characters. Only someone with the correct decryption key can convert the ciphertext back into readable plaintext. Encryption is the foundational technology that makes private communication and secure transactions possible on the internet.

What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses the same key for both encrypting and decrypting data. It is fast and efficient, making it suitable for encrypting large amounts of data. The challenge is that both parties need to have the same key, which creates a problem for securely sharing it in the first place. Asymmetric encryption uses a mathematically linked pair of keys: a public key that anyone can use to encrypt data, and a private key that only the owner has, used to decrypt it. Asymmetric encryption solves the key exchange problem but is computationally slower. Modern systems typically use asymmetric encryption to exchange a symmetric key, then switch to symmetric encryption for the actual data transfer.

What is end-to-end encryption?

End-to-end encryption (E2EE) means that data is encrypted on the sender's device and can only be decrypted on the recipient's device. No intermediary, including the service provider whose servers the data passes through, can read the content. WhatsApp, Signal, and iMessage use end-to-end encryption for messages. This is in contrast to transport encryption, where the service provider can read data on its servers but encrypts it in transit. E2EE provides much stronger privacy protection but complicates law enforcement access and content moderation.

How does HTTPS encryption work?

HTTPS uses a protocol called TLS (Transport Layer Security) to encrypt the data traveling between your browser and a website's server. When you connect to an HTTPS site, your browser and the server perform a handshake where they verify the server's identity using a digital certificate, negotiate which encryption algorithm to use, and securely exchange the encryption key. All data including the page content, form submissions, and cookies is then encrypted in both directions. The padlock icon in your browser indicates that TLS encryption is active.

What are AES and RSA and how do they differ?

AES (Advanced Encryption Standard) is a symmetric encryption algorithm that uses the same key to encrypt and decrypt data. It operates on fixed-size blocks of data and is the global standard for symmetric encryption, used in everything from Wi-Fi security to disk encryption. RSA (Rivest-Shamir-Adleman) is an asymmetric encryption algorithm based on the mathematical difficulty of factoring the product of two large prime numbers. RSA uses a public-private key pair and is widely used for secure key exchange and digital signatures. In practice, AES encrypts the bulk data while RSA handles the secure exchange of the AES key.

Can encryption be broken?

Modern encryption algorithms using sufficiently long keys are computationally infeasible to break with today's technology. Breaking 256-bit AES encryption by brute force would take longer than the age of the universe even with the most powerful computers. However, encryption can fail through other means: poor implementation of the algorithm, compromised keys, weak passwords used to protect keys, vulnerabilities in the software using encryption, or quantum computing advances that may eventually threaten current public key cryptography. Key management and proper implementation are where most real-world encryption failures occur.

What does encryption protect against and what does it not protect against?

Encryption protects data confidentiality: it prevents unauthorized parties from reading intercepted data in transit and prevents access to stored data if a device or server is physically stolen or remotely compromised. It is effective against eavesdropping, man-in-the-middle attacks, and data theft. However, encryption does not protect against malware that captures data before it is encrypted, against attacks on the endpoints where data is decrypted, against weak passwords or poor key management, or against social engineering that tricks users into revealing keys or credentials. Encryption is one layer of a complete security strategy, not a complete solution on its own.

What is key management and why does it matter?

Key management refers to the full lifecycle of creating, distributing, storing, rotating, and destroying the cryptographic keys that protect encrypted data. Keys are the foundation of encryption security: the strongest encryption algorithm is useless if the keys protecting it are poorly managed. Common key management failures include storing keys alongside the encrypted data they protect, using weak or predictable keys, failing to rotate keys periodically, and not revoking keys when personnel with access leave an organization. Enterprise key management systems address these challenges systematically, and cloud providers offer dedicated key management services.

What is encryption at rest versus encryption in transit?

Encryption in transit protects data while it is moving across networks, like when you send a message or load a web page. HTTPS and TLS provide this type of protection. Encryption at rest protects data while it is stored, such as on a hard drive, database, or cloud storage service. Full disk encryption tools like BitLocker and FileVault protect data at rest on devices. Cloud providers offer encryption at rest for stored data. Both types are needed for comprehensive protection: encrypting only data in transit leaves stored data vulnerable if systems are compromised.

What threat does quantum computing pose to encryption?

Quantum computers, once sufficiently powerful, could break the mathematical problems that underpin current asymmetric encryption systems like RSA and elliptic curve cryptography. Specifically, quantum algorithms like Shor's algorithm could factor large numbers and solve discrete logarithm problems exponentially faster than classical computers. Symmetric encryption like AES is more resistant but would need longer key lengths to remain secure. Cryptographers are actively developing post-quantum cryptography standards that will be resistant to quantum attacks, and governments and major technology organizations are beginning to plan migrations to these new algorithms before large-scale quantum computers become practical.