Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Cryptography fundamentals for engineers are no longer optional theory reserved for security specialists; they are baseline requirements for building compliant, resilient cloud infrastructure. When you configure a load balancer, rotate database credentials, or sign container images, you are making cryptographic decisions that directly impact your system's integrity and audit posture. This guide strips away the academic abstraction to focus on the applied primitives, protocols, and operational patterns you actually encounter in production environments.
What Are the Core Cryptography Fundamentals for Engineers?
At the operational level, cryptography solves three specific problems: keeping data secret, proving data hasn't changed, and verifying identity. Confusing these primitives is the most common source of security vulnerabilities I see during infrastructure audits. Encryption provides confidentiality but does not guarantee integrity; an attacker can flip bits in a ciphertext stream without knowing the key. Hashing guarantees integrity but provides zero confidentiality. Digital signatures bind identity to data.
For modern infrastructure, you must distinguish between symmetric and asymmetric operations. Symmetric algorithms (AES-256-GCM, ChaCha20-Poly1305) handle bulk data encryption because they are fast. Asymmetric algorithms (RSA-4096, ECDSA P-256/P-384, Ed25519) handle key exchange and signing because they enable trust without shared secrets. Never use raw RSA for encrypting application data; it is slow and padding-oracle attacks are subtle. Always use hybrid schemes where asymmetric crypto establishes a session key for symmetric encryption.
In my work preparing teams for SOC 2 and ISO 27001 audits, the most frequent finding isn't weak algorithms—it's misapplied ones. Using MD5 for checksums is acceptable; using it for password storage is a critical failure. Understanding Kubernetes secrets management done right requires knowing why base64 encoding is not encryption and why etcd encryption at rest matters. Similarly, when you handle secrets in CI/CD pipelines safely, you're applying these exact primitives to prevent credential leakage during build processes.
How Does TLS 1.3 Handshake Actually Work?
TLS 1.3 is the current standard for transport security, and understanding its handshake is essential for debugging latency and certificate issues. Unlike TLS 1.2, which required two round trips, TLS 1.3 completes the handshake in one round trip (1-RTT) for new connections and zero round trips (0-RTT) for resumption. This performance gain comes from combining key exchange and authentication into the ClientHello message.
The 1-RTT Handshake Sequence
- ClientHello: The client sends supported cipher suites, key shares (typically X25519 or P-256), and signature algorithms. Crucially, it includes the key share upfront, not in a separate ServerKeyExchange step.
- ServerHello + EncryptedExtensions: The server selects parameters, provides its key share, and immediately switches to encrypted communication. Everything after ServerHello is encrypted, including the certificate.
- Certificate + CertificateVerify: The server proves ownership of the private key by signing the handshake transcript. This replaces the old ServerKeyExchange signature.
- Finished: Both parties confirm the handshake integrity. Application data can flow immediately after the server's Finished message.
This design eliminates downgrade attacks and removes support for legacy, broken ciphers. TLS 1.3 only supports AEAD (Authenticated Encryption with Associated Data) ciphers: AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305. CBC mode and RC4 are gone. If you're still seeing TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA in your logs, something is misconfigured or running outdated software.
A common mistake in 2026 is disabling TLS 1.3 "for compatibility." Modern browsers and cloud providers have supported it for years. Disabling it forces fallback to weaker ciphers and adds latency. When configuring Nginx or HAProxy, explicitly set ssl_protocols TLSv1.3 TLSv1.2; and prefer server-side cipher ordering. For deeper network configuration context, see the Ubuntu security hardening guide which covers TLS stack tuning alongside OS-level controls.
When Should You Use Hashing Versus Encryption?
This distinction causes more production incidents than almost any other cryptographic confusion. Encryption is reversible; hashing is not. If you need to retrieve the original data, use encryption. If you need to verify data or store credentials, use hashing. Never encrypt passwords; hash them with a memory-hard function.
| Criterion | Encryption (AES-GCM, ChaCha20) | Hashing (SHA-256, Argon2id) |
|---|---|---|
| Reversibility | Reversible with correct key | One-way; computationally infeasible to reverse |
| Primary Use Case | Data confidentiality (at rest/in transit) | Integrity checks, password storage, deduplication |
| Output Length | Same as input + tag overhead | Fixed length regardless of input size |
| Key Required | Yes (symmetric or asymmetric) | No (except HMAC/KDF variants) |
| Password Storage | NEVER — key compromise exposes all passwords | ALWAYS — use Argon2id or bcrypt with salt |
| Tamper Detection | AEAD provides authentication, but decryption needed | Instant comparison without secret material |
For password hashing in 2026, Argon2id is the recommended algorithm. It resists both GPU parallelization and side-channel attacks by requiring configurable memory and time costs. Bcrypt remains acceptable for legacy systems but lacks memory hardness. SHA-256 alone is never appropriate for passwords, even with salt; it's too fast and allows billions of guesses per second on commodity hardware.
# Generate Argon2id hash with recommended parameters
# Memory: 64 MiB, Iterations: 3, Parallelism: 4
echo -n "user_password" | argon2 salt_value -id -t 3 -m 16 -p 4
# Verify hash programmatically (Python example)
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)
hash = ph.hash("user_password")
ph.verify(hash, "user_password") # Returns True or raises exceptionFor integrity verification of files, container images, or API payloads, SHA-256 or BLAKE3 are appropriate. BLAKE3 offers superior performance on modern CPUs while maintaining security margins. When signing artifacts for supply chain security, combine hashing with asymmetric signatures using tools like Sigstore Cosign, not bare hashes.
How Do You Manage Keys and Secrets in Production?
Cryptographic strength is irrelevant if keys are stored in plaintext configuration files or committed to Git. Proper key management separates the data encryption key (DEK) from the key encryption key (KEK). This envelope encryption pattern is foundational to AWS KMS, GCP Cloud KMS, Azure Key Vault, and HashiCorp Vault.
Envelope Encryption Workflow
- Generate DEK locally: Create a random symmetric key in application memory. Never transmit the plaintext DEK.
- Encrypt data with DEK: Use AES-256-GCM to encrypt your payload. Store the ciphertext and nonce/tag alongside the data.
- Encrypt DEK with KEK: Call the KMS API to encrypt the DEK. The KMS never sees your data, only the small DEK.
- Store encrypted DEK: Persist the encrypted DEK next to the ciphertext. Discard the plaintext DEK from memory immediately.
- Decrypt on read: Retrieve encrypted DEK → call KMS to decrypt → use recovered DEK to decrypt data → wipe DEK from memory.
This pattern limits blast radius. Compromising the database gives an attacker only encrypted data and encrypted DEKs. They cannot decrypt without also compromising the KMS, which has separate access controls, audit logging, and rotation policies. For Kubernetes environments, integrate external secrets operators to inject decrypted values at runtime rather than storing them in etcd. The secrets management with HashiCorp Vault guide details dynamic secret generation and lease-based revocation, which further reduces exposure windows.
Key rotation deserves special attention. Rotate KEKs annually or after suspected compromise. With envelope encryption, rotating the KEK doesn't require re-encrypting terabytes of data—only re-encrypting the small DEKs. Automate this process; manual rotation fails under pressure. For Nepal-based fintech or healthtech companies handling sensitive data under local regulatory expectations, envelope encryption with region-local KMS endpoints satisfies data residency requirements while maintaining global security standards.
Applying Cryptography Fundamentals for Engineers in Production
Mastering cryptography fundamentals for engineers means moving beyond textbook definitions to operational discipline. Start by auditing your current stack: verify TLS versions and cipher suites with nmap --script ssl-enum-ciphers, check password hashing algorithms against Argon2id/bcrypt standards, and confirm all secrets use envelope encryption or a managed secrets service. Remove every instance of plaintext credentials in code, configs, and environment variables. Implement automated scanning with tools like Gitleaks and Trivy in your CI pipeline to catch regressions before deployment.
Security is not a feature you add later; it's an architectural constraint you design around from day one. Whether you're securing a Laravel API, hardening a Kubernetes cluster, or preparing for your first SOC 2 audit, these cryptographic primitives form the foundation of trust. If your team needs hands-on guidance implementing these patterns or preparing infrastructure for compliance review, reach out to discuss your specific architecture. Getting cryptography right prevents breaches that no amount of monitoring can fix after the fact.
