What is decryption? Meaning, keys and examples

Decryption is the process of turning encrypted data (ciphertext) back into its original, readable form (plaintext) using the correct key. It is the second half of encryption: the algorithm is public, and only whoever holds the right key can reverse the scrambling. Every time a browser shows an HTTPS page, a phone opens a WhatsApp message or an app plays a paid lecture, something has just been decrypted.

Decryption, decoding and cracking

If you need a refresher on plaintext, ciphertext and keys, start with our guide to what encryption is. This article covers the other side: what happens when data is turned back into something readable, who holds the key at that moment, and why that moment matters so much for security.

First, a distinction that clears up a lot of confusion. Decryption is only one of three ways people talk about "getting the data back":

So a "Base64 decrypt" tool is really a decoder (see why Base64 isn't encryption), and "decrypting" a SHA-256 hash is impossible, because a hash has no key to reverse.

A worked example: decrypting with AES-GCM

Modern systems use authenticated encryption, which checks that the ciphertext hasn't been altered before it releases any plaintext. AES in GCM mode is the most common choice. To decrypt, the receiver needs up to five inputs:

• The key: 16 or 32 random bytes, known only to authorised parties.
  
  
• The nonce: a 12-byte value used once per message. It isn't secret and travels with the ciphertext.
  
  
• The ciphertext itself.
  
  
• The authentication tag: 16 bytes that let the receiver detect any change.
  
  
• Associated data (optional): context that isn't encrypted but must match exactly, such as a student ID.
  
  

Here is the whole round trip in Python, using the widely used cryptography library:

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

key = AESGCM.generate_key(bit_length=128)  # the shared secret
nonce = os.urandom(12)                       # never reuse with this key
box = AESGCM(key)

ct = box.encrypt(nonce, b"Polity lecture 14", b"student_4821")
print(box.decrypt(nonce, ct, b"student_4821"))  # b'Polity lecture 14'

box.decrypt(nonce, ct, b"student_9999")  # raises InvalidTag

Authenticated decryption either returns the exact original bytes or refuses. A wrong key, a single flipped bit in the ciphertext or a different student ID each raise InvalidTag, and no plaintext comes out. Older modes such as CBC behave differently: a wrong key produces random-looking garbage, and a tampered ciphertext can decrypt "successfully" into altered text. That difference is the heart of AES-GCM vs AES-CBC.

Symmetric and asymmetric decryption

In symmetric decryption, the key that encrypted the data also decrypts it. AES and ChaCha20 work this way, and they are fast enough to decrypt video segments, disk blocks and network traffic in real time.

In asymmetric decryption, data encrypted with someone's public key can be decrypted only with the matching private key. RSA with OAEP padding is the classic example. It is slow and handles only small inputs: an RSA-2048 key with OAEP and SHA-256 can carry at most 190 bytes in one go. So in practice the private key recovers a small symmetric key, and that key decrypts the actual data. Many modern protocols skip even that step. TLS 1.3 derives fresh symmetric keys through a key agreement, and the server's private key only signs the handshake; no page is ever "decrypted with the private key".

Our comparison of symmetric vs asymmetric encryption explains why real systems combine the two.

What a decryption key is

A decryption key is the secret value the algorithm needs to reverse the encryption. For AES it is 128 or 256 random bits. For RSA it is the private exponent, a number about as long as the key size, so 2,048 bits or more. Without it, correctly encrypted data stays unreadable, which is why a lost key usually means lost data.

Real systems use several kinds of keys, often in layers:

• Session keys are created for one connection, such as a single HTTPS session, and thrown away afterwards.
  
  
• Content keys encrypt a particular file or video, sometimes changing every few segments.
  
  
• Key-encryption keys encrypt other keys. A cloud key service keeps the master key and hands out only wrapped data keys, which is how good encryption key management keeps the most important secret in one guarded place.
  
  
• Password-derived keys come from something you know. Apple says an iPhone's passcode is entangled with a secret unique to the device, and each guess is calibrated to take about 80 milliseconds, so guessing has to happen on the phone itself, slowly (Apple Platform Security).
  
  

Where decryption happens in real systems

Notice the pattern. A CDN that terminates HTTPS sees your traffic in plain form, and an unlocked phone has already done the decrypting for every app. Encryption protects data in transit and at rest; at the point of use, the data is plain again.

Video players follow the same rule. In standard HLS streaming, the playlist names a URL from which the player fetches a 16-byte AES-128 key, and the player decrypts each segment before decoding it (RFC 8216). How that key URL is protected decides most of the security, as our guide to HLS encryption explains.

Why attackers target the moment of decryption

Breaking AES or a 2,048-bit RSA key by brute force is not realistic. Waiting for the data to be decrypted is. At that moment the key, or a way to use it, is on the device, and the plaintext exists in memory and on the screen. The common routes are:

1. The key delivery. If a key URL or licence server hands keys to anyone holding a copied link, the encryption adds little.
   
   
2. Keys inside the app. A key hard-coded in an Android or iOS app can be found by anyone who unpacks the app.
   
   
3. A modified or instrumented device. On a rooted phone, an emulator or with a debugger attached, an attacker can observe the app while it decrypts.
   
   
4. The output. Decrypted video ends up as pixels, which can be screen-recorded or filmed with a second phone.
   
   
5. A legitimate account. A shared login decrypts content exactly as the paying student would.
   
   

Hardware key storage helps with the second route but not the others. Android's documentation is candid about the limit: if an app's process is compromised, the attacker "might be able to use the app's keys", even though the key material can't be extracted from secure hardware (Android Keystore). No single control covers every route, so when you assess a video platform, ask about each one:

• Who can obtain a key or licence, and how long does it keep working?
  
  
• Are any keys built into the app itself?
  
  
• What happens on rooted phones, emulators and modified apps? This is the territory of runtime application self-protection (RASP).
  
  
• What happens when a screen recording starts, or when a second phone films the screen?
  
  
• If a lecture leaks anyway, can the copy be traced back to the account it came from?
  
  
• How is one login stopped from serving a whole group?
  
  

Key takeaways

• Decryption turns ciphertext back into plaintext with the right key. Decoding needs no key, and cracking tries to get around the key.
  
  
• Authenticated modes such as AES-GCM either return the exact original or refuse; older modes can return garbage or quietly altered data.
  
  
• Symmetric keys decrypt bulk data. Private keys mostly recover, or help agree, small symmetric keys.
  
  
• Browsers, CDNs, phones and video players all decrypt, and data is plain at the point of use.
  
  
• Attackers target key delivery, the device and the screen, so protection must cover the moment of decryption, not just the file.
  
  

VidSafe protects coaching institutes' lectures with VidSafe proprietary encryption, RASP, screen- and camera-recording detection, account-sharing prevention, PDF watermarking, and visible and invisible watermarks that are extremely hard to remove, even after heavy re-encoding.

Frequently asked questions

What is a decryption key?

A decryption key is the secret value an algorithm needs to turn ciphertext back into readable data. In symmetric systems such as AES it is the same key that encrypted the data, usually 128 or 256 random bits. In asymmetric systems such as RSA it is the private key, which matches a public key that anyone may use to encrypt. Whoever holds the decryption key can read the data, so it must be stored and shared with great care.

What is decryption, with an example?

Decryption reverses encryption. When you open an HTTPS site, your browser and the server agree on a session key, the server sends encrypted data, and your browser uses that key to decrypt it into the page you see. A simpler example: a file encrypted with AES under a shared key is decrypted by the recipient with the same key, and if even one bit of the ciphertext was changed, authenticated decryption rejects it.

Why is decryption needed?

Encrypted data is useless until someone entitled to read it decrypts it. Decryption gives the intended recipient, device or service the original data back: your phone reading its own storage after you unlock it, a server reading a form you submitted over HTTPS, or a student's app playing a lecture. Encryption isn't meant to hide data from everyone, only to make sure that key holders alone can read it.

Can encrypted data be decrypted without the key?

Not if a modern algorithm is used properly. Trying every possible AES-128 or AES-256 key is far beyond any computer. In practice attackers go around the maths: they guess the weak password a key was derived from, steal the key from an app or server, exploit a buggy implementation, or wait for the data to be decrypted on a device. Our guide on whether encrypted data can be hacked covers each route.