What Is Decryption? Keys, Algorithms and Where IT Sees It

Every encrypted laptop, HTTPS session and ransomware note ends at the same question: who holds the key that turns the data back into something readable? That one question decides whether a lost laptop is a non-event, whether a firewall can inspect traffic, and whether a ransomware victim pays. This post explains what decryption is, how the two key models work, and the three places IT teams meet it every week.

What Is Decryption?

NIST defines decryption as the process of changing ciphertext into plaintext using a cryptographic algorithm and a key. Plaintext is the readable file. Ciphertext is the same file after encryption: bytes that carry no meaning until the key is applied. Decryption runs the algorithm in reverse, and with the right key it takes milliseconds.

The algorithm is not the secret. AES, the cipher behind BitLocker, FileVault and the TLS session in your browser, has been published since 2001, and that openness is the point: thousands of people have tried to break it in public. The key is the only secret. If a vendor tells you their encryption is strong because the method is private, that is a warning sign, not a feature. Our guide to what a cipher is covers the algorithm side in more depth, so this post stays on the key.

Two things get confused with decryption. Decoding reverses a public transformation with no key, so Base64 or URL encoding can be undone by anyone. Cryptanalysis is recovering plaintext without the key, by finding a flaw in the algorithm or by guessing. For AES-128 guessing means trying up to 2^128 keys. Nobody is doing that this decade, which is why the attacks that work go after the key, not the maths.

Symmetric and Asymmetric Decryption

Symmetric decryption uses the same key that encrypted the data. AES, specified in FIPS 197, comes in 128, 192 and 256-bit key lengths and works on 128-bit blocks. It is fast, modern CPUs accelerate it in hardware, and it carries nearly all the bulk data you encrypt: disks, backups, database columns, the body of a TLS session. The hard part is getting the one key to the other side without anyone copying it on the way.

Asymmetric decryption solves that delivery problem with a key pair. Anyone can encrypt with the public key; only the private key decrypts. RSA and elliptic-curve exchanges are slow, so they are used on small values, which in practice means other keys. The pair agrees or wraps a session key, and the session key does the decrypting. That is how TLS, SSH and code signing work, and it is why a leaked private key is a bigger event than a leaked session key: one opens every session, the other opens one.

The next change is already published. NIST's FIPS 203, released in August 2024, standardises ML-KEM, a key-encapsulation mechanism designed to survive quantum computers. The reason it matters now rather than later is a tactic called harvest now, decrypt later: record encrypted traffic today, decrypt it when the maths catches up. Browsers and major CDNs started hybrid post-quantum key exchange in 2024 and 2025, so the switch is already happening underneath you.

TLS: Decryption Happens at the Endpoint

TLS 1.3, defined in RFC 8446, agrees a fresh session key for every connection, and every key exchange it allows provides forward secrecy. Static RSA key exchange is gone. Everything after the ServerHello is encrypted. The practical consequence for IT: the only two parties who can decrypt a TLS session are the two endpoints, and a recorded session cannot be opened later with the server's private key.

That is why SSL inspection on a firewall is not passive. The firewall terminates the client's session, decrypts it, inspects the content, then opens a second session to the real server and re-encrypts. Your devices only accept this because you pushed the firewall's certificate to them. Anything that pins its certificate, which includes banking apps, many update services and some health platforms, breaks, and each one you add to the bypass list is traffic you no longer see.

The r/sysadmin thread below asked in June 2025 whether SSL decryption was worth the effort, and the replies land on the same trade: real visibility into what leaves the network, paid for with a bypass list that needs a maintainer.

BitLocker and FileVault: The Recovery Key Is the Decryption Key

On a managed Windows laptop the AES key that decrypts the volume is sealed inside the TPM. A normal boot unseals it with no prompt. Microsoft's BitLocker recovery overview lists what breaks that silence: too many wrong PINs, firmware or boot order changes, a cleared TPM, docking changes on some models. The drive then refuses to decrypt until someone types the recovery password, a 48-digit number Microsoft recommends storing in Entra ID or Active Directory. Our BitLocker guide covers turning it on and escrowing the key across a fleet.

Nothing else decrypts that drive. There is no vendor back door and no support line that can help. If the password was never escrowed, the recovery prompt is the moment the data is gone, and the ticket ends in a reimage. FileVault works the same way on a Mac: a personal or institutional recovery key, escrowed to the MDM, is the only path back in when the user's password fails. Our FileVault explainer goes through the escrow step for Apple fleets.

The pattern to notice is that disk encryption moves the risk from the disk to the key store. A stolen laptop with an escrowed key is a small ticket. A working laptop with no escrowed key is a disaster waiting for a firmware update.

Ransomware: When Someone Else Holds the Key

Ransomware is decryption with the key in the wrong hands. The malware encrypts files with a key only the operator holds, and the ransom note is an offer to sell it back. CISA's #StopRansomware guide tells victims to consult federal law enforcement before anything else, including about decryptors, because researchers and police operations sometimes recover keys. The No More Ransom project, run by Europol and its partners, lists more than 200 decryptor entries on its tools page as of October 2026, each tied to a specific family and often to specific variants.

That last part is where hope meets the version number. The r/sysadmin thread below, from June 2026, is an Akira victim working with a DFIR firm who has already found that the public Avast decryptor does not cover the newer variants. Our guide to how a ransomware attack unfolds covers the first hour; the decryption question comes after it.

The gate that ends most incidents is not a decryptor. It is a backup the attacker could not reach, which is why the operators go for backups first and why immutable backups exist. Paying buys a key, maybe: it can arrive late, decrypt only some files, or not arrive at all, and the data was often copied before it was encrypted. And whatever route you take, the malware comes off the machine first, or the files are encrypted again the moment they are restored.

What to Check This Week

The three cases above share one lesson: the algorithm is never the weak point, the key's location is. A short audit of where your keys live covers more risk than any algorithm choice.

• BitLocker and FileVault recovery keys escrowed for every device, and a restore of one key tested from the admin console.
• Backup encryption keys stored somewhere the backup job cannot delete, and included in the disaster recovery test.
• TLS 1.2 as the floor on every server and 1.3 where the stack allows it, with legacy cipher suites off.
• The SSL inspection bypass list reviewed, with an owner and a date on every exception.
• Certificate private keys inventoried, with expiry dates and a named person who can rotate them.

OpenFrame can run a script across a client's devices that reports BitLocker protection status and the TLS versions each endpoint still accepts, with the output collected in one place. The point of the exercise is the same whichever tool runs it: a list of every key, where it lives, and who can reach it.

The Short Version

Decryption is encryption run backwards with the right key, and the algorithm doing it is public. AES decrypts the bulk; a key pair delivers the key. TLS decrypts only at the endpoints, BitLocker decrypts only with the TPM or the escrowed password, and ransomware decrypts only with a key you do not have. Every one of those is a question about key custody, so start with the list of where your keys live. From there, the cipher guide covers which algorithms to turn off, and the BitLocker guide covers escrow across a fleet.