Gossips on Cryptography: Part 4

In this blog, we will continue our discussion from the previous parts. If you have not read them, please read them first.

• Parts 1 & 2 – Caesar Cipher, Vigenere Cipher, Symmetric Encryption, AES, Convergent Encryption, IV
• Part 3 – Hashing, Salting, Rainbow Table Attacks, Asymmetric Encryption, RSA

In Part 3, we teased a few topics for Part 4 — Envelope Encryption, PKI, and more. Today we gossip about exactly those! Let's go.

First, A Quick Revisit: Convergent Encryption

We discussed Convergent Encryption back in Parts 1 & 2, but let's revisit it here because it connects beautifully to Envelope Encryption.

Remember? Convergent Encryption means — if you encrypt the same plaintext with the same key and the same IV, you will always get the same ciphertext.

So Why Is That Useful?

Imagine you work at a big company. 500 employees all upload the same file — let's say the company's HR policy PDF. If you use regular encryption (different ciphertext every time), your storage system stores 500 different encrypted copies. That's 500x storage wasted!

With Convergent Encryption, since the same file + same key = same ciphertext, the storage system realizes — "Hey, I already have this encrypted file!" — and stores only ONE copy. All 500 employees point to the same encrypted blob. This is called deduplication.

This is exactly how Dropbox, Google Drive, and AWS S3 save enormous amounts of storage at their scale.

Another Use Case — Searching Over Encrypted Data

Here is another very powerful use case of Convergent Encryption that most people don't think about — searching.

Imagine you have a database where all the data is encrypted. A user wants to search for records where the email is "[email protected]."

With regular encryption, every time "[email protected]" is encrypted, it produces a **different** ciphertext (because of a random IV). So to search, you would have to:

1. Decrypt every single record in the database
2. Compare the plaintext
3. Return the matches

That is insanely expensive! Imagine doing this on a database with 100 million records. Your server will cry. 

Now with Convergent Encryption — "[email protected]" always produces the **same** ciphertext. So to search, you just:

1. Encrypt the search term "[email protected]" once
2. Look for that ciphertext in the database — just like a normal indexed search!
3. Return the matches 

No decryption needed at all! The data stays encrypted at rest, and you can still do fast, exact-match searches on it.

This is called searchable encryption, and it is used in scenarios like:

• Encrypted databases where you still need to support queries
• Healthcare systems — searching patient records without ever exposing raw data
• Email systems — searching your encrypted inbox without the server ever seeing your emails in plain text

Pretty powerful, right? Same property (deterministic output) — two completely different superpowers (deduplication + searchable encryption).

But wait — there's a catch. If two people can produce the same ciphertext, can someone guess your file? Yes, this is called a confirmation attack. Someone could hash a known file, compare it with stored hashes, and confirm whether you uploaded that file. So Convergent Encryption is great for performance and deduplication but is used carefully in highly sensitive scenarios.

Now Let's Talk About Envelope Encryption

Okay, so now we know — encryption needs keys. And those keys need to be stored somewhere safely. But here's the problem — who encrypts the key itself?

If your key is lying around in plain text, a hacker who gets access to your server gets everything. So the answer is — we encrypt the key too!

This is the core idea of Envelope Encryption.

The Two Keys in Envelope Encryption

• DEK — Data Encryption Key. This is the key that directly encrypts your actual data. Think of it as the key to your diary.
• KEK — Key Encryption Key. This is the master key that encrypts the DEK. Think of it as the key to your locker — inside which you keep your diary key.

So the flow looks like this:

Your Data   →   encrypted with DEK   →   Encrypted Data

DEK         →   encrypted with KEK   →   Encrypted DEK

You store both — the Encrypted Data and the Encrypted DEK — together. The KEK lives safely inside a highly secure system (like AWS KMS or Vault).

Real-Life Example — The Bank Locker

Imagine you have an important document (your data). You put it in a box and lock it with a small key (DEK). Now you don't want to carry this small key everywhere — so you put the small key inside your bank locker (encrypt DEK with KEK). The bank locker key (KEK) stays with the bank in a highly secure vault.

To read your document:

1. Go to the bank → get your small key out (decrypt DEK using KEK)
2. Use the small key to open the box (decrypt data using DEK)

Simple! And very secure.

Why Not Just Encrypt Data Directly With KEK?

Two very practical reasons:

1. Performance

The KEK usually lives inside a secure hardware vault or cloud service (like AWS KMS). If you send your entire 10GB file to KMS every time you want to encrypt or decrypt — that's painfully slow and expensive. Instead, you only send the tiny DEK (a few bytes) to KMS. The heavy lifting of encrypting actual data is done locally with the DEK.

2. Key Rotation

Say after 6 months you want to change your encryption key (key rotation is a security best practice). Without envelope encryption — you'd have to decrypt ALL your data and re-encrypt it with a new key. Imagine doing that for terabytes of data!

With Envelope Encryption — you only re-encrypt the DEK with the new KEK. Your actual data stays untouched. Much faster, much cheaper.

Where Is Envelope Encryption Used?

Literally everywhere in the cloud world:

• AWS S3 – When you enable server-side encryption on a bucket
• AWS RDS – When you enable encryption on a database
• GCP Cloud Storage – Envelope encryption is the default
• Azure Key Vault – Same pattern

Every time you see that little "encryption enabled" checkbox on a cloud service — envelope encryption is what's happening under the hood.

Now Let's Talk About PKI

PKI stands for Public Key Infrastructure.

In Part 3, we discussed Asymmetric Encryption — where you have a Public Key and a Private Key. Sounds great in theory. But here's a real problem.

The Trust Problem

Imagine Rahul wants to send an encrypted message to Priya. Priya shares her public key with Rahul. Rahul encrypts the message with Priya's public key and sends it.

But wait — how does Rahul know that the public key he received is actually Priya's? What if a hacker intercepted the communication and swapped Priya's public key with their own? Rahul encrypts with the hacker's public key → hacker decrypts → reads the message. This is called a Man-in-the-Middle (MITM) Attack.

We need someone that both Rahul and Priya trust, who can say — "Yes, this public key truly belongs to Priya." That trusted someone is called a certificate authority (CA).

PKI — The Complete Picture

PKI is a system made up of several components that together solve the trust problem. Let's go one by one.

1. Certificate Authority (CA)

A CA is a trusted organization whose job is to verify identities and issue digital certificates. Think of them like the government passport office — they verify who you are and give you an official identity document (passport).

Well-known CAs in the real world: DigiCert, Let's Encrypt, GlobalSign, Comodo.

Your browser/OS comes pre-loaded with a list of trusted CAs. That's how your browser automatically trusts websites — because their certificates were signed by a CA your browser already trusts.

2. Digital Certificate

A Digital Certificate is like a government-issued ID card for websites (or people or servers). It contains:

• The owner's name (e.g., google.com)
• The owner's Public Key
• The CA's name (who issued it)
• Expiry date
• A digital signature from the CA

When you open https://google.com — your browser checks Google's certificate. It sees the CA that signed it. It checks if that CA is in its trusted list. If yes — green light, connection is secure! That's the lock you see.

3. Digital Signature

We talked about hashing in Part 3 — that you cannot reverse a hash. Digital Signatures use this + asymmetric encryption together in a clever way.

When a CA wants to sign a certificate, it:

1. Takes the certificate content and hashes it
2. Encrypts that hash with its own Private Key

That encrypted hash = Digital Signature.

Anyone can verify the signature using the CA's Public Key (which is publicly available). If the decrypted hash matches the actual certificate content → the certificate is genuine and untampered! 

Think of it like a wax seal on an envelope. Anyone can see the seal, but only the king's ring (private key) could have made it.

4. Certificate Chain (Chain of Trust)

In the real world, CAs have a hierarchy:

Root CA  →  Intermediate CA  →  Your Website Certificate

The Root CA is the ultimate trusted authority. It signs Intermediate CAs. Intermediate CAs sign individual website certificates. This chain is called the Chain of Trust.

Why this hierarchy? Security! Root CA private keys are kept in ultra-secure, air-gapped hardware. They are almost never used directly. Intermediate CAs do the day-to-day certificate signing. If an Intermediate CA is ever compromised, it can be revoked without affecting the Root CA.

Where Is PKI Used in Real Life?

PKI is literally everywhere. You just don't see it because it works silently in the background.

1. HTTPS Websites (SSL/TLS)

Every https:// website uses PKI. When you open your bank's website — a PKI handshake happens in milliseconds:

1. Your browser asks the bank's server for its certificate
2. The bank's server sends its Digital Certificate
3. Browser verifies the certificate using the CA's public key
4. If valid → browser and server agree on a secret key (using asymmetric encryption)
5. All further communication uses that secret key with AES (fast symmetric encryption)

That's TLS in a nutshell. And PKI is the backbone of all of it.

2. Email Signing (S/MIME)

When your company sends you a digitally signed email — PKI is involved. The sender signs the email with their private key. You verify it with their public key from their certificate. You can be sure the email is genuinely from them and was not tampered with in transit.

3. Code Signing

When you download an app or a software update — how does your phone/OS know it's legit and not malware? The developer signs the app with their private key. Your phone verifies it using the developer's certificate. This is why on Android you see the "Install from unknown sources" warning — no valid certificate found!

4. Government and Banking

Your Aadhaar card, digital signatures on GST filings, net banking OTPs — all of these use PKI infrastructure behind the scenes. India's government runs its own CA called CCA (Controller of Certifying Authorities) under the IT Act.

5. VPNs and Internal Company Networks

When you connect to your company's VPN, PKI certificates are used to verify that you are connecting to the genuine company server and not an imposter.

Terms We Have Learned So Far (All 4 Parts)

• Cryptography, Algorithm, Plain Text, Key, Cipher Text
• Symmetric Encryption, Convergent Encryption, Initialization Vector (IV), Searchable Encryption
• Hashing, Hash/Digest, Avalanche Effect
• Salt, Rainbow Table Attack, Confirmation Attack
• Asymmetric Encryption, Public Key, Private Key, RSA
• DEK (Data Encryption Key)
• KEK (Key Encryption Key)
• Envelope Encryption
• Key Rotation, Deduplication
• PKI (Public Key Infrastructure)
• Certificate Authority (CA)
• Digital Certificate
• Digital Signature
• Chain of Trust
• TLS/SSL

That's a solid vocabulary now! 

Coming in Part 5... 

(Part 5 is in progress — stay tuned!)

In the next part, we will gossip about:

• SSL/TLS Deep Dive – The full step-by-step TLS handshake explained simply
• mTLS (Mutual TLS) – How microservices talk to each other securely
• HSM (Hardware Security Module) – The physical vault where the most sensitive keys live
• Zero-Knowledge Proofs – Proving you know something without revealing what it is
• And more...

Stay tuned for Part 5! 

If you liked this blog, do give it a like and share it with someone who you think should learn this. Let's spread the knowledge!

Read the previous parts here: 

• Part 1 & 2 
• Part 3