Encryption Basics: Symmetric, Asymmetric and Signatures

You protect against one risk and leave the others open. Stored data can be read by the wrong person, a secret may need to reach someone you share no key with, and data can be quietly changed. Each risk needs a different tool.

Picture a common setup. A document-vault app stores families' wills, property sale deeds, land records and insurance papers, about 3 lakh (300,000) files in all. The setup is made up, but the three problems are real.

One week, a courier loses a backup disk that was being moved between two data centres. The team now has three questions, and this guide answers each one.

• If a stranger plugs in that disk, can they read anyone's will?
• A lawyer wants to send a family a new property paper. How can she make sure only that family can open it?
• Years from now, a court may ask whether a stored will is exactly what the family uploaded. How can anyone prove that?

The first question is about keeping stored data secret. The second is about sending a secret to someone you have never shared a key with. The third is not about secrecy at all.

The encryption basics every developer should know are five words and one idea. The idea: each tool protects one specific property, so you name the property before you pick the tool.

Plaintext and ciphertext. Plaintext is readable data, such as the PDF of a will. Ciphertext is the scrambled version after encryption. Without the right key, ciphertext looks like random bytes.

Key. A key is a secret random value that controls the scrambling, 16 or 32 bytes for the common AES key sizes. The method itself is public. Only the key is secret, so guarding the key is most of the job.

Cipher. A cipher is the method that turns plaintext into ciphertext and back. AES, the Advanced Encryption Standard, is the cipher this guide uses for stored data.

Hash. A hash function turns any data into a short, fixed-size fingerprint, with no key at all. SHA-256 always gives 32 bytes, and the same file always gives the same hash.

You cannot compute the file back from its hash. You can, however, hash guesses and compare them, which matters for short secrets like passwords.

Security people describe what a tool protects with three words. Each one matches part of the team's three questions.

• Confidentiality: only the right people can read the data. This is the lost-disk question.
• Integrity: nobody changed the data without being caught. This is half of the court question.
• Authenticity: you know who the data really came from. This is the other half of the court question.

Symmetric encryption uses the same secret key to encrypt and to decrypt. Whoever holds that one key can both lock the data and read it again.

Think of a steel trunk with one padlock and two copies of its key. Two people each keep a copy. Either can lock the trunk and either can open it. Anyone else who gets a copy can do both too.

That picture shows the strength and the weakness. Symmetric ciphers are fast. But both sides must already share the key, and passing a copy safely is hard.

AES is defined in FIPS 197, a United States government standard published in November 2001. It encrypts data in 128-bit blocks, with keys of 128, 192 or 256 bits. The May 2023 update changed the wording only, not the algorithm.

In the diagram below, follow one will from the upload to the disk and back.

So the answer to the lost-disk question is no, as long as the disk never held the keys. The backup job copied only ciphertext, and the keys live in a separate key service.

Why AES-GCM and not plain AES

AES on its own scrambles one 16-byte block at a time, so you always use it in a mode, a recipe for handling a whole file. The vault uses GCM mode, a form of authenticated encryption. It hides the data and adds a 16-byte tag, a short check value, that detects any change.

GCM also needs a nonce, short for number used once. NIST recommends 12 bytes, and a nonce must never repeat with the same key. It is not secret, so you store it next to the ciphertext.

Here is the vault's helper, using the Python cryptography library, tested on version 50.0.2. In real code the data key comes from the key service. The last four lines create a test key and check the result.

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

def encrypt_paper(data_key, paper_bytes, family_id):
    nonce = os.urandom(12)                 # fresh for every file
    aad = family_id.encode()               # checked, but not hidden
    ciphertext = AESGCM(data_key).encrypt(nonce, paper_bytes, aad)
    return nonce + ciphertext              # keep the nonce with the file

def decrypt_paper(data_key, stored, family_id):
    nonce, ciphertext = stored[:12], stored[12:]
    return AESGCM(data_key).decrypt(nonce, ciphertext, family_id.encode())

data_key = AESGCM.generate_key(bit_length=256)    # 32 random bytes
stored = encrypt_paper(data_key, b"x" * 1000, "family-42")
print(len(stored))                                          # 1028
print(decrypt_paper(data_key, stored, "family-42") == b"x" * 1000)  # True

Three lines matter most. The os.urandom(12) call makes a fresh random nonce for each file. The aad value is associated data: the family id is not encrypted, but it is bound to the file.

What just happened? A 1,000-byte file came out as 1,028 bytes: 12 bytes of nonce plus 16 bytes of tag. Run it after pip install cryptography==50.0.2 and you will see the same two lines.

That binding matters. If a bug tries to open one family's will under another family's id, decryption fails. So does a change to any single byte, or the wrong key. In each case the library raises InvalidTag instead of returning garbage.

Asymmetric encryption, also called public-key encryption, uses two linked keys. Data locked with the public key opens only with the matching private key, which never leaves its owner.

Picture the letterbox outside a flat in a housing society. It has a slot at the front and a small locked door at the back. Anyone walking past can drop a letter through the slot. Only the owner, with the one back-door key, can take letters out.

The slot is the public key: you can tell the whole city where it is. The back-door key is the private key: the owner never copies it or hands it over. Where the picture breaks: a letterbox lock can be picked, but the private key cannot practically be worked out from the public key on today's computers.

This answers the lawyer question. The lawyer and the family have never met or shared a secret. The family's app creates a key pair on their phone and gives the vault only the public half. The lawyer can then lock a paper only the family can open.

The two common families are RSA and elliptic-curve methods. RSA rests on how hard it is to factor huge numbers. Elliptic curves get strong security from far shorter keys: an Ed25519 public key, used for signatures later in this guide, is 32 bytes. An RSA-2048 modulus alone is 256 bytes.

Look at where each key sits in the diagram. The public key travels freely. The private key stays on the phone.

Why real systems use hybrid encryption

Public-key encryption has a hard size limit. RSA encryption uses a padding scheme called OAEP. With a 2048-bit key and OAEP with SHA-256, one operation locks at most 190 bytes. In our test, 191 bytes failed with a ValueError.

It is also slow. On our test machine, AES-256-GCM encrypted 4 MiB (about 4.2 million bytes) in a few milliseconds or less. One RSA-2048 operation on at most 190 bytes took about 0.1 ms to encrypt and 0.7 ms to decrypt. Per byte, RSA was over 1,000 times slower in every run (rough timings that varied run to run, not a benchmark).

So real systems use hybrid encryption. The lawyer's app makes a fresh random AES key, encrypts the paper with it, then locks only that 32-byte AES key with the family's public key. The family's private key opens the AES key, and the AES key opens the paper.

You can check the sizes yourself. Locking a 32-byte AES key with an RSA-2048 public key gives exactly 256 bytes, and the private key returns the same 32 bytes.

Symmetric encryption uses one shared key for both directions and is fast, while asymmetric encryption uses a public and private key pair and is slow. Symmetric protects the bulk of the data, and asymmetric solves how strangers share a key.

The table adds digital signatures, which the next section covers, because people mix all three up. Read it one row at a time.

A digital signature proves two things: the data was signed by whoever holds a particular private key, and it has not changed since. It does not keep the data secret.

Anyone can read a signed will. The signature does not hide a word. It shows who signed that exact sequence of bytes, and the check fails if even one comma changes.

Signing swaps the roles of the two keys. You make a signature with your private key, which only you hold. Anyone with your public key can check it.

RSA signatures and ECDSA, NIST's long-standing elliptic-curve signature scheme, first hash the document and sign that short fingerprint. Plain Ed25519 skips that separate step and feeds the whole message into its signing maths, using SHA-512 inside.

NIST's signature standard, FIPS 186-5 from February 2023, says signatures detect unauthorised changes and authenticate the signer. A receiver can also use one to show a third party who signed. NIST calls that non-repudiation: the signer cannot easily deny it later.

This answers the court question. When a family uploads a will, the vault signs the exact file bytes plus the upload date. Years later, a lawyer or court can check it with the vault's published public key.

Signing and checking a will in Python

This sketch uses Ed25519, an elliptic-curve signature scheme that FIPS 186-5 approves and says gives about 128 bits of security. In production the private key sits inside a key service, not in a Python variable.

from cryptography.exceptions import InvalidSignature
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

signing_key = Ed25519PrivateKey.generate()   # kept by the vault only
verify_key = signing_key.public_key()        # shared with lawyers and courts

will = b"Uploaded 2026-10-15. I leave the Mohali flat to my daughter."
signature = signing_key.sign(will)           # stored with the will

def is_unchanged(document, signature):
    try:
        verify_key.verify(signature, document)
        return True
    except InvalidSignature:
        return False

print(len(signature))                                              # 64
print(is_unchanged(will, signature))                               # True
print(is_unchanged(will.replace(b"daughter", b"son"), signature))  # False

Pause and predict: the last line changes one word of the will but reuses the old signature. Will the check pass?

What just happened? It prints 64, then True, then False. The verify call returns nothing on a match and raises InvalidSignature otherwise. One changed word is enough to fail.

Here is the same check as a decision.

Be honest about the limit. This signature proves the file has not changed since the vault received it. It does not prove the person named in the will wrote it. That needs the will's own legal signing process.

How a signature differs from a hash or an HMAC

A plain hash catches changes, but anyone who alters a file can compute a fresh hash, so it proves nothing about who. An HMAC is a hash mixed with a shared secret key. GitHub, for example, signs each webhook delivery with HMAC-SHA256 and a secret both sides hold.

But an HMAC cannot convince an outsider. Both sides hold the same key, so either could have made the tag. A signature can, because only one party holds the private key.

Real systems use symmetric keys for the data, use public-key methods to share or protect those keys, and use signatures to prove which keys and files are genuine. Each tool covers a gap another leaves.

HTTPS is the everyday example. It runs on TLS, the protocol that secures web traffic. In a full TLS 1.3 handshake, defined in RFC 8446, both sides agree on fresh session keys with Diffie-Hellman. That method lets each side combine its own private value with the other's public value and reach the same secret without sending it.

The server then proves its identity by signing the handshake with its certificate's private key. After that, authenticated ciphers such as AES-GCM carry the page. RFC 8446 removed the old static RSA key exchange, so TLS 1.3 never sends the session key locked with RSA.

For stored files, the common pattern is envelope encryption. Each file gets its own random data key. That data key is then encrypted, or wrapped, by a master key held in a key management service (KMS), a separate system built only to guard keys. Some services keep keys in a hardware security module, a tamper-resistant device that uses keys without revealing them.

Google Cloud KMS documents the pattern this way: the key that wraps data keys never leaves the KMS. The vault stores only wrapped data keys next to its files.

Here is the full picture. Follow the will from the family's phone into storage.

Rotation is where envelope encryption pays off. In Google Cloud KMS, rotating a key makes a new primary version, which is used for new encryption. Old data is not re-encrypted automatically (as of 19 October 2026).

For symmetric keys, Cloud KMS picks the older version needed to decrypt, as long as that version is not disabled, scheduled for destruction or destroyed. So old wills still open. When the team wants old files on the new version, it rewraps 3 lakh small data keys, not 3 lakh whole documents.

The mistakes below break encryption without touching the cipher, which NIST still approves. A review of the vault's code checks for each of these mistakes.

• Keys stored next to the data. A key in the same backup as the ciphertext is like taping the padlock key to the trunk. Keep keys in a key service.
• Keys committed to code. Deleting the file does not remove a committed key from Git history or from clones made since. Rotate that key, load keys at runtime, and scan repositories for secrets.
• Reused nonces. One fixed nonce in a config file breaks GCM for every file under that key. Generate each nonce in code.
• Encryption without integrity. ECB mode turns two identical 16-byte blocks into identical ciphertext, which leaks patterns. Plain CBC mode without a separate check can let changes go unnoticed. Use an authenticated mode like GCM.
• Homemade crypto. Inventing your own cipher or wiring parts together yourself is easy to get wrong. Use a well-reviewed library and its high-level functions.
• Encrypting passwords. Hash them with a slow password hash instead. The OWASP cheat sheet names Argon2id first, then scrypt, with bcrypt for legacy systems.
• Ignoring a failed check. Catching InvalidTag or InvalidSignature and carrying on anyway throws away the whole protection.

One more risk is easy to forget. If you lose the key, you lose the data, with no recovery. The vault's key service keeps master key backups in a second region, under separate access.

What quantum computers change

Wills stay valuable for decades, so the team also plans for quantum computers. A large enough quantum computer could break RSA and elliptic-curve methods. NIST warns of harvest now, decrypt later: attackers storing encrypted data today to break it later.

NIST's transition plan, IR 8547, was still an initial public draft from November 2024 as of 19 October 2026. NIST rates each setting by security strength in bits, where n bits means roughly 2 to the power n steps to break it. The draft proposes deprecating, meaning discouraging, RSA and elliptic-curve settings rated at 112 bits after 2030. It proposes disallowing all of them after 2035.

Symmetric tools are far less exposed. The same draft says NIST does not expect to move away from its symmetric standards, and it lists AES-128, AES-192 and AES-256. Replacements for public keys exist: FIPS 203 (ML-KEM, for agreeing on keys) and FIPS 204 (ML-DSA, for signatures), both published on 13 August 2024.

1. 1

   Keep AES for the data

   AES stays in NIST's draft plan at all three key sizes. The vault keeps AES-256 for its long-lived papers as extra margin.

2. 2

   List every public-key use

   Write down each place that uses RSA, elliptic curves or Ed25519: TLS, the lawyer flow and will signing.

3. 3

   Make algorithms swappable

   Store the algorithm name with each signature, so a post-quantum scheme such as ML-DSA can be added without breaking old records.

4. 4

   Watch the final plan

   Check each year whether NIST has finalised IR 8547 and whether the 2030 and 2035 dates moved.

Explain encryption by naming what each piece protects, then showing where each key lives. Key handling tells an interviewer far more than cipher maths does.

1. 1

   Name the threats

   Say what could go wrong: stolen disks, snooping on the network, or changed records. Tie each one to confidentiality, integrity or authenticity.

2. 2

   Protect data in transit

   Say that every hop uses TLS, including internal service calls when the data is sensitive.

3. 3

   Protect data at rest

   Describe AES-GCM with envelope encryption: one data key per object, wrapped by a master key in a key management service.

4. 4

   Add signatures where proof matters

   Sign records that someone outside your system must trust later, such as receipts, audit logs or stored legal papers.

5. 5

   Show key handling

   Explain who can unwrap keys, how rotation works, where key backups live, and that every key use is logged.

6. 6

   Admit the cost

   Mention the extra latency of key service calls, and that caching unwrapped data keys briefly in memory trades a little risk for speed.