Foundations of Symmetric Encryption

Symmetric encryption is the use of a single secret key, shared by both sender and receiver, to transform plaintext into ciphertext and back.

The word symmetric describes the relationship between the two keys involved in the operation: there is only one. The same secret value that scrambles the data is the value that unscrambles it. If two people both hold a copy of the key, either can encrypt to the other and either can decrypt from the other. The math runs in both directions.

Contrast this with asymmetric encryption, which uses a key pair (one public, one private) and which we cover in a different track. For now, hold one rule in your head: same key both ways.

Before going further, pin these definitions down. Every chapter that follows will use them constantly, and confusion between them is the single most common reason cryptography material feels harder than it is.

In 1883, the Dutch cryptographer Auguste Kerckhoffs wrote down what is now a non-negotiable rule of modern cryptography:

In other words, your algorithm is not your secret. Your key is your secret. There is a reason every well-known cipher has its full specification published, peer-reviewed, attacked for decades, and only then standardized. The strength comes from the math holding up under public scrutiny, not from hiding the recipe.

The opposite approach is called security through obscurity: keeping the algorithm itself secret and hoping no one figures it out. It does not work. It has never worked at scale. Every proprietary cipher trotted out under that banner (A5/1 in GSM phones, the CSS algorithm in DVDs, MIFARE Crypto-1 in transit cards) has eventually been reverse engineered and broken. Treat any vendor pitching a secret-sauce algorithm as a vendor pitching a vulnerability.

Asymmetric encryption gets the publicity (HTTPS, code signing, SSH key login), but symmetric encryption is what actually moves the bytes. Three reasons:

It is fast.

Symmetric ciphers, especially AES with hardware acceleration (the AES-NI instruction set on modern CPUs), run at gigabytes per second. RSA, by comparison, struggles to encrypt a few megabytes per second on the same hardware. Encrypting a 10 GB disk with RSA is not on the table. Encrypting it with AES is routine.

It uses short keys.

A 256-bit symmetric key (32 bytes) provides 256 bits of security. To reach equivalent security with RSA, you need a key around 15,000 bits long. Short keys make symmetric encryption efficient to store, transmit, and process.

It is the workhorse, every time.

When a TLS session establishes itself, asymmetric cryptography is used briefly to negotiate a shared secret. The moment that shared secret exists, both ends switch to symmetric encryption for the rest of the conversation. The asymmetric part is the handshake. The symmetric part is the actual data. Every TLS-protected webpage you have ever loaded was protected by symmetric encryption for the substance of the transfer.

If symmetric encryption is so fast and so strong, why is asymmetric encryption used at all? Because symmetric encryption has a problem that the math itself cannot solve.

This is the chicken-and-egg situation that drove cryptographers for decades before public key cryptography solved it in the 1970s. You cannot just email the key. You cannot just put it in a configuration file checked into git. You cannot just print it on a sticky note. Anywhere the key travels in the open, an attacker can capture it, and once they hold the key, the encryption protects nothing.

The full course of action for handling this problem (key exchange protocols, key derivation, key storage, key rotation, key revocation) is the subject of the Key Management Basics page later in this track. For now, understand that the algorithm is the easy part. The key, and where it lives, and who else can reach it, is the hard part.

Symmetric algorithms fall into two structural families based on how they consume the plaintext:

Block ciphers

Process the plaintext in fixed-size chunks. AES uses 128-bit blocks (16 bytes at a time). If the plaintext is 5,000 bytes long, AES will not see the plaintext as a stream. It will see it as 312 full blocks plus a partial block that needs padding. Each block is encrypted as a unit. Block ciphers also need a mode of operation to define how multiple blocks chain together, which we cover on the next page.

Stream ciphers

Generate a pseudorandom keystream from the key and XOR it byte-by-byte (or bit-by-bit) against the plaintext. ChaCha20 and the older RC4 are stream ciphers. They do not need padding, they do not need block alignment, and they are often faster in software where hardware AES acceleration is unavailable. Conceptually they imitate a one-time pad with a pseudorandom keystream substituted for the truly random pad.

The line between them blurs in practice. Running AES in CTR (counter) mode effectively converts the block cipher into a stream cipher, because it generates a keystream by encrypting successive counter values and XORing that keystream against the plaintext. You get the well-studied core of AES with the flexibility of a stream cipher.

For this course, the focus stays on block ciphers (specifically AES) because they dominate everything from disk encryption to TLS to VPNs. Stream ciphers come up in specialized contexts and have their own dedicated page later in the track.

Before moving to the next page, confirm you can answer the following without looking:

1. What is the defining property of a symmetric cipher?
2. What is Kerckhoffs's Principle, and why does it rule out security through obscurity?
3. Why is symmetric encryption typically used for bulk data even when asymmetric encryption is also in play?
4. What is the one fundamental problem that symmetric encryption alone cannot solve?
5. What is the structural difference between a block cipher and a stream cipher?

If any of those are wobbly, scroll back. If all five are solid, you are ready for AES.