Encryption Demystified: Symmetric, Asymmetric, Hashing Explained

We had built the product. Internally, we call it DevOps Genie - the market name is still under wraps. But the product worked. Features were solid, the UI was clean, customers were evaluating it.

But we had not thought about two things: license enforcement and encryption of backups.

It sounds obvious in hindsight. You build a product, you ship it to customer sites, and then one morning you realize - there is nothing stopping a customer from copying the binary to ten machines. There is nothing stopping someone from taking a database backup, emailing it to a competitor, and exposing every credential stored in the system.

We had built a product without building the locks.

And here is the thing about adding encryption after the fact - you cannot just “bolt it on.” Every cryptographic decision shapes how the product deploys, how licenses are validated, how backups are created and restored, and what happens when a customer calls you at 11 PM saying they have lost access to their data.

We were deploying at customer sites, not in our cloud. That changes everything. You cannot just “reset the password” or “check the database.” Once the binary ships, every cryptographic decision is baked in.

This forced us to learn encryption not from textbooks, but from real engineering constraints. This article is part one of that journey - a practitioner’s walkthrough of the encryption fundamentals every developer and architect should understand.

The Two Worlds of Encryption

Every encryption conversation starts with one fundamental split: symmetric and asymmetric.

Most developers have heard these terms. Few have had to choose between them under real constraints.

Symmetric Encryption: One Key, Both Sides

Symmetric encryption uses the same key to encrypt and decrypt. Think of it as a padlock where both parties hold identical keys.

How it works:

1
2

Plaintext + Key → Ciphertext
Ciphertext + Same Key → Plaintext

Common algorithms:

Why AES-256-GCM dominates:

• Authenticated encryption - it encrypts AND verifies integrity in one operation
• Hardware acceleration - modern CPUs have AES-NI instructions, making it fast
• GCM mode provides both confidentiality and tamper detection - if someone modifies even one bit of the ciphertext, decryption fails

When we needed to encrypt customer backups containing database credentials and API keys, AES-256-GCM was the obvious choice. We needed authenticated encryption - if a backup file gets corrupted or tampered with, we want decryption to fail loudly, not silently produce garbage. More on that in an upcoming article on how we built our licensing and encryption system.

Asymmetric Encryption: Two Keys, Different Roles

Asymmetric encryption uses a key pair - a public key and a private key. What one encrypts, only the other can decrypt.

How it works:

1
2

Plaintext + Public Key → Ciphertext (only Private Key can decrypt)
Plaintext + Private Key → Signature (Public Key can verify)

Common algorithms:

Why Ed25519 is winning:

• 256-bit key vs RSA’s 4096-bit - smaller, faster, equally secure
• Deterministic signatures - same input always produces same signature (no randomness bugs)
• Resistant to timing attacks by design
• The signature is only 64 bytes - compact enough for license files, SSH keys, or JWTs

When we chose Ed25519 for our product’s licensing system, the deciding factor was startup performance. The binary validates the license on every boot - milliseconds matter. RSA would have worked, but Ed25519 was faster and simpler.

Hashing: The One-Way Function

Hashing is not encryption. This distinction matters.

Encryption is reversible (with the right key). Hashing is not. A hash function takes any input and produces a fixed-size output. You cannot recover the original input from the hash.

Common hash algorithms:

What “broken” means for MD5 and SHA-1:

It does not mean someone can reverse the hash. It means someone can craft two different inputs that produce the same hash (collision). For security purposes - digital signatures, certificates, integrity verification - that is fatal.

Where hashing shows up in practice:

• Key derivation - deriving an AES encryption key from a license signature or passphrase
• Password storage - bcrypt and Argon2 are hash-based (you verify by re-hashing, never decrypting)
• Integrity verification - checksums for downloads, container image digests, git commits
• Content addressing - S3 ETags, IPFS CIDs, deduplication systems

In our product, we used SHA-256 to derive unique per-customer encryption keys from their license signatures. No key storage infrastructure needed - the license itself becomes the key material. The full design is covered in the upcoming licensing article.

Encryption at Rest vs In Transit

These terms come up in every compliance conversation, every security audit, every customer questionnaire. They sound straightforward, but the implementation choices behind them are anything but.

Encryption at Rest

Data at rest is data stored somewhere - a disk, a database, an S3 bucket, a backup file. Encrypting it means that if someone gains physical or logical access to the storage, they see ciphertext, not data.

Layers where it can happen:

The critical question is not “is it encrypted?” but “encrypted at which layer, and who holds the key?”

Full-disk encryption protects against physical theft. It does nothing if an attacker has database credentials - the database decrypts transparently for any authenticated user. Column-level encryption protects even against a compromised database, but adds application complexity.

Several of our customers are particular about encryption of their data in PostgreSQL, MongoDB, and S3. The nuances of database encryption - what exactly gets encrypted, at which layer, and the real-world trade-offs - deserve their own deep dive. That is coming next in this series.

Encryption in Transit

Data in transit is data moving between systems - API calls, database connections, file transfers, replication traffic.

The standard: TLS (Transport Layer Security).

1
2

Client → TLS Handshake (asymmetric: ECDHE + Ed25519/RSA) → Shared Secret
Client ↔ Server (symmetric: AES-256-GCM with shared secret)

TLS combines asymmetric and symmetric encryption in one protocol:

1. Asymmetric (slow) to exchange a session key securely
2. Symmetric (fast) for the actual data transfer
3. Certificates (signatures) to verify server identity

Where teams often miss it:

• Database connections without TLS (PostgreSQL sslmode=disable is still common)
• Internal service-to-service traffic assumed “safe” because it is on a private network
• Replication traffic between database nodes
• Backup transfers to object storage

If you have worked with secret management in Kubernetes, you know this pattern - the secret is only as secure as the weakest link in the chain. Encrypting secrets in Vault means nothing if the application fetches them over an unencrypted connection.

Choosing the Right Tool: A Decision Framework

After two decades of building production systems, here is how I think about encryption choices:

When to Use What

Common Mistakes I Have Seen

1. Using encryption when you need hashing - Storing encrypted passwords instead of hashed passwords means a key leak exposes all passwords at once

2. Using MD5 or SHA-1 for security - These are broken for security purposes. Use SHA-256 minimum

3. Rolling your own crypto - Use standard library primitives. The creativity belongs in the architecture, not the cryptography

4. Encrypting without authenticating - AES-CBC without HMAC lets attackers modify ciphertext undetected. AES-GCM handles both

5. Assuming disk encryption protects against application-level attacks - Full-disk encryption stops physical theft. It does nothing once the OS is booted and the volume is mounted

6. Skipping TLS for internal traffic - “It is on a private network” is not a security strategy. Lateral movement after a breach is real

7. Confusing compliance checkboxes with actual security - “Encryption at rest: enabled” on an S3 bucket means nothing if the bucket policy allows public read access

The Trust Question

Every encryption system eventually comes down to trust: who holds the keys?

This is true whether you are managing BitLocker recovery keys escrowed to Microsoft, AWS KMS keys controlled by Amazon, or your own master signing key stored offline.

The algorithm is rarely the weak point. The key management is.

Questions worth asking for any encrypted system:

• Who can access the decryption keys?
• Under what conditions are keys released?
• What happens if the key holder is compromised?
• Can a single entity (including you) unilaterally decrypt everything?
• Is key rotation possible without downtime?

We faced exactly these questions when designing the encryption and licensing system for DevOps Genie. The answers involved Ed25519 digital signatures, dual-envelope AES-256-GCM encryption, and some hard trade-offs between recoverability and zero-trust. That story is coming in the third article of this series.

The Quantum Threat: What Changes and What Does Not

No encryption article in 2026 is complete without addressing the elephant in the room: quantum computing.

The concern is real, but the panic is often misplaced. Here is what actually matters.

What Quantum Computing Breaks

A sufficiently powerful quantum computer running Shor’s algorithm can efficiently solve the mathematical problems that underpin asymmetric encryption:

Every asymmetric algorithm in use today is theoretically vulnerable to a large-scale quantum computer.

What Quantum Computing Does NOT Break

Symmetric encryption and hashing are far more resilient:

AES-256 with 128-bit effective security in a post-quantum world is still stronger than what most systems use today. If you are already on AES-256, your symmetric encryption is quantum-safe.

“Harvest Now, Decrypt Later”

This is the real and present danger, not a future one.

Nation-state actors and sophisticated adversaries are already collecting encrypted traffic and storing it. The bet: when quantum computers become capable enough, they will decrypt the stored data retroactively.

This means:

• Data encrypted today with RSA or ECDH key exchange could be decrypted in 10-15 years
• Long-lived secrets (state secrets, medical records, financial data with decades of relevance) are at risk NOW
• Data that loses value quickly (session tokens, short-lived API keys) is less affected

Post-Quantum Cryptography: The Mitigations

NIST finalized its first post-quantum cryptography standards in 2024:

What you should be doing now:

1. Inventory your cryptographic dependencies - Know where RSA, ECDSA, Ed25519, and DH are used in your systems
2. Ensure AES-256 everywhere - If you are still on AES-128, migrate now. AES-256 is your quantum insurance for symmetric encryption
3. Watch for hybrid modes - TLS 1.3 implementations are adding hybrid key exchange (classical + post-quantum). Chrome and Cloudflare already support ML-KEM hybrid
4. Plan, but do not panic - Production-ready quantum computers capable of breaking current encryption are estimated at 10-15+ years away. But migration takes time, so starting the inventory now is prudent
5. Prioritize long-lived data - If your encrypted data must remain confidential for decades, consider hybrid encryption schemes today

For the Practitioner

If you are building systems today:

• AES-256-GCM for data encryption - already quantum-resistant
• SHA-256/SHA-512 for hashing - already quantum-resistant
• Ed25519 for signatures - still safe for now, plan migration path to ML-DSA
• TLS 1.3 with hybrid key exchange - available now in major implementations
• Do not wait for “quantum-safe” before shipping - the transition will be gradual, and hybrid approaches bridge the gap

The quantum threat is real but manageable. Your symmetric encryption (AES-256) and hashing (SHA-256) are safe. Your asymmetric encryption (RSA, Ed25519) has a migration path via NIST post-quantum standards. The biggest risk is ignoring the “harvest now, decrypt later” threat for long-lived sensitive data.

What Comes Next

This article is part one of a three-part series born from real production decisions:

Part 1: Encryption Demystified (this article) The fundamentals - symmetric, asymmetric, hashing, at rest vs in transit. The building blocks you need before making architecture decisions.

Part 2: Database Encryption - What It Actually Means PostgreSQL TDE vs filesystem encryption vs column-level. MongoDB encrypted storage engine. S3 SSE-S3 vs SSE-KMS vs client-side. What “encryption at rest” really protects against (and what it does not). Drawn from real customer requirements.

Part 3: Encryption and Licensing - How We Built It The complete DevOps Genie story - Ed25519 license signing, AES-256-GCM dual-envelope backup encryption, key derivation from license signatures, the master key trust model, and the trade-offs we made shipping a product deployed at customer sites.

Frequently Asked Questions

What is the difference between encryption and hashing?

Encryption is reversible with the correct key - you can get the original data back. Hashing is a one-way function - you cannot recover the original input. Use encryption when you need to retrieve the data later. Use hashing when you need to verify data (passwords, checksums) without storing the original.

Why use Ed25519 instead of RSA for digital signatures?

Ed25519 provides equivalent security to RSA-3072 with much smaller keys (32 bytes vs 384 bytes), faster signing and verification, deterministic signatures (no randomness bugs), and built-in resistance to timing attacks. For new systems, Ed25519 is the better default.

What is authenticated encryption and why does it matter?

Authenticated encryption (like AES-256-GCM) provides both confidentiality and integrity in a single operation. Without authentication (plain AES-CBC), an attacker can modify encrypted data without detection. With GCM, any tampering causes decryption to fail, alerting you to the modification.

Is full-disk encryption enough to protect my database?

No. Full-disk encryption (LUKS, BitLocker) protects against physical theft of the storage media. Once the system boots and the volume is mounted, the operating system and any authenticated user can read the data in plaintext. For protection against application-level or network-level attacks, you need database-level or column-level encryption.

What is the difference between encryption at rest and in transit?

Encryption at rest protects stored data (on disk, in a database, in object storage). Encryption in transit protects data moving between systems (over a network). Most production systems need both - they solve different threat models.

Is SHA-256 secure for key derivation?

For deriving keys from high-entropy sources (like a cryptographic signature), SHA-256 is appropriate. For deriving keys from passwords (low entropy), use purpose-built KDFs like Argon2, scrypt, or PBKDF2 that add computational cost to resist brute force attacks.

Will quantum computers break all encryption?

No. Quantum computers threaten asymmetric encryption (RSA, ECDSA, Ed25519) via Shor’s algorithm. Symmetric encryption (AES-256) and hashing (SHA-256) remain secure - Grover’s algorithm only halves their effective strength, which still leaves them beyond brute force. NIST post-quantum standards (ML-KEM, ML-DSA) provide migration paths for asymmetric algorithms. The practical risk today is “harvest now, decrypt later” for long-lived sensitive data.