Encryption Explained

Encryption is not one thing. It is a small set of primitives used in different places, with different parties holding keys and different failure modes. Most confusion about “is this secure” comes from not knowing which kind is in play.

The two primitives you need

Symmetric encryption. One secret key encrypts and decrypts. Fast, and the right tool for bulk data. AES in a proper mode is the default choice; see NIST SP 800-38A for the mode choices and SP 800-57 for key policy.

Asymmetric encryption. A key pair, one public and one private. The public half encrypts, the private half decrypts. It is slow, and its real purpose is distribution: solving the problem of agreeing a shared secret over a channel you do not yet trust.

In practice both are used. TLS 1.3 uses asymmetric cryptography to establish a shared secret, then symmetric cryptography for the connection.

The two places it is used

In transit. TLS protects a connection from both ends to whoever terminates it. The security property is not “encrypted” but “encrypted to an authenticated endpoint”. If the endpoint’s certificate is validated, a network attacker cannot read or modify the connection.

At rest. Data is encrypted on the device or the disk. See full-disk encryption.

End-to-end. Only the endpoints can decrypt. This is a statement about who holds keys, and it is stronger than transport encryption, where the server necessarily holds a key. See end-to-end encrypted messaging.

Four misconceptions

Claim	Reality
“Encrypted, so nobody can see it”	Only the parties who hold a key. Metadata is unaffected.
“It’s custom crypto, so it’s stronger”	Standard, reviewed primitives outperform novel ones almost every time.
“A long key length makes it unbreakable”	Key length is rarely the constraint. Implementation and key management are.
“No one has broken AES”	Nobody has needed to. Modern attacks target implementation, endpoints, and passwords.

Kerckhoffs’s principle

If an algorithm is assumed secret, it may be assumed insecure.

The security of a system must rest entirely on the secrecy of its keys, never on the secrecy of its design. Every standard cryptographic primitive used today is public, specified, and attacked in the open. That is the point.

What actually breaks encryption

1. The endpoint. Malware running as you reads plaintext before encryption and after decryption. This is the most common failure by a wide margin.
2. The key. A key in a configuration file, in a repository, in a backup, or known to an adversary through legal process. See key management.
3. The implementation. Buffer handling, nonce reuse, padding oracles, and memory disclosure. Heartbleed is a bounds-check bug with a CVSS score near perfect and enormous reach.
4. The downgrade. Old, weak protocol versions kept enabled for compatibility. A protocol that can be downgraded to a broken version is broken.

Sources

• RFC 8446 — TLS 1.3, and the design decisions that removed downgrade and compression-related weaknesses.
• NIST SP 800-57 Part 1 Rev. 5 — key management, the part that actually determines whether encryption helps.
• NIST SP 800-38A — block cipher modes, and why the mode choice is not optional.