AES, RSA, DES Encryption Explained: What Actually Matters in Production
AES, RSA, DES, ECC, ChaCha20, post-quantum cryptography explained with real production trade-offs, code examples, key management lifecycle, and the mistakes that get systems pwned.
N
NarenFounder & Principal Engineer
20+ years shipping performance-critical code where algorithms decide the bill. Notes here come from systems that actually shipped.
AES-GCM is the default for new projects: authenticated encryption with integrity checks.
RSA is for wrapping ephemeral keys, not encrypting payloads directly. Use OAEP padding, never PKCS#1 v1.5.
ECC (ECDH, ECDSA) provides equivalent security with much smaller keys. P-256 is the safe default.
ChaCha20-Poly1305 is faster than AES-GCM on devices without hardware acceleration.
Nonce reuse breaks GCM and ChaCha20 completely. Use SecureRandom, never counters or timestamps.
Key management is the most common failure: use envelope encryption with a KMS.
Post-quantum: ML-KEM and ML-DSA are NIST standards. Start hybrid migration now.
✦ Definition~90s read
What is Encryption Algorithms?
Encryption algorithms are the mathematical primitives that transform plaintext into ciphertext and back, but in production systems they are never used in isolation. They solve the problem of confidentiality (keeping data secret) and integrity (ensuring data hasn't been tampered with), but they don't solve authentication, key distribution, or replay protection — those require protocols like TLS 1.3 or SSH.
★
Imagine you run a postal service.
The choice of algorithm directly impacts performance, security posture, and compliance: use the wrong one and you'll either leak data or burn CPU cycles for no benefit.
DES and 3DES are historical artifacts that should be dead in 2026. DES's 56-bit key can be brute-forced in under a day with consumer hardware (a $10 FPGA cluster cracks it in minutes). 3DES triples the key size but still operates on 64-bit blocks, making it vulnerable to Sweet32 birthday attacks.
Any production system still using these is a compliance violation waiting to happen — PCI DSS and NIST have deprecated them. Replace immediately with AES.
AES-GCM is the default choice for most production workloads: it's an authenticated encryption (AEAD) cipher that provides both confidentiality and integrity in a single pass. On modern x86 CPUs with AES-NI instructions, AES-256-GCM encrypts at 1-2 GB/s per core.
Use it for TLS, disk encryption (LUKS), and database field encryption. ChaCha20-Poly1305 is the alternative when hardware acceleration is absent — mobile devices, IoT, or older ARM chips. It's roughly 3x faster than AES in software and equally secure; Google uses it in TLS for Android and Chrome.
RSA is not a general-purpose encryption algorithm — it's a trapdoor permutation for key exchange and digital signatures. Encrypting data directly with RSA is slow (max ~200 bytes per 2048-bit key) and dangerous (padding oracle attacks). Use RSA only for encrypting symmetric keys (like AES session keys) or signing certificates.
ECC (Elliptic Curve Cryptography) achieves equivalent security with much smaller keys: 256-bit ECC ≈ 3072-bit RSA. But ECC has less headroom — a quantum computer would break 256-bit ECC faster than 3072-bit RSA due to Shor's algorithm scaling. For now, use X25519 for key exchange and Ed25519 for signatures; they're faster and safer than NIST P-256.
Plain-English First
Imagine you run a postal service. Symmetric encryption (AES) is like a lockbox where you and your friend both have identical keys fast, efficient, great for heavy packages. Asymmetric encryption (RSA) is like a mail slot on your front door: anyone can drop a letter in (encrypt with your public key), but only you have the key to open the box (private key). DES is the lockbox your grandfather used in 1977 the key is so short a determined thief can try every possible combination over a weekend. ECC is a smaller, smarter lock that gives you the same security as a massive RSA lock in a fraction of the size. And post-quantum cryptography is the lock designed to survive the day someone builds a quantum computer powerful enough to pick all the locks we use today. The whole modern cryptography stack is just figuring out which box to use, when, and how not to leave the key taped to the lid.
A fintech startup I consulted for was encrypting customer PII with DES in 2019. Not 3DES. Plain, single DES. The dev who wrote it had copy-pasted a Stack Overflow answer from 2004, the code passed every code review because nobody checked the cipher string, and it sailed into production for three years. When a penetration tester cracked a sample in under four hours on a laptop, the incident report was brutal. The kicker? The fix was literally changing one string from 'DES/ECB/PKCS5Padding' to 'AES/GCM/NoPadding'. Three years of exposure from one lazy string.
Encryption is the one area of software engineering where 'good enough' is catastrophically different from 'correct'. A slightly inefficient database query costs you milliseconds. A slightly broken cipher costs you your users' data, your compliance certifications, and potentially your company. The gap between AES-GCM and AES-ECB isn't academic ECB mode leaks structural patterns in your plaintext, meaning an attacker can detect when two encrypted values are identical without ever decrypting them. RSA with PKCS#1 v1.5 padding versus OAEP isn't a footnote PKCS#1 v1.5 is vulnerable to Bleichenbacher's attack, a padding oracle exploit that has broken real TLS implementations in production. These distinctions are not theoretical.
After reading this you'll be able to make a deliberate, defensible algorithm and mode choice for a new service, read a cipher string like 'AES/GCM/NoPadding' and know exactly what each segment means and why it matters, spot the three most common encryption anti-patterns in a code review, and have a clear mental model for when to use symmetric versus asymmetric encryption and when to combine them, which is what every TLS handshake on the planet does. We'll also cover ECC as the modern replacement for RSA, post-quantum migration planning, ChaCha20-Poly1305 for non-hardware-accelerated platforms, key management lifecycle, encrypted search patterns, and the gritty details of side-channel attacks.
What Encryption Algorithms Actually Do — and Don't
Encryption algorithms transform plaintext into ciphertext using a key, ensuring that only parties with the matching key can reverse the transformation. The core mechanic is a mathematical operation — substitution, permutation, or modular exponentiation — that is computationally easy with the key but infeasible without it. In production, the choice of algorithm determines your threat model coverage, not just secrecy.
Symmetric algorithms like AES use the same key for encryption and decryption, operating on fixed-size blocks (128 bits for AES) through repeated rounds of substitution and permutation. Asymmetric algorithms like RSA use a public-private key pair, where the public key encrypts and the private key decrypts — relying on the computational hardness of factoring large primes. Key length is the dominant factor: AES-128 offers 128-bit security, while RSA-2048 provides roughly 112-bit security due to sub-exponential attacks.
Use symmetric encryption for bulk data (files, database columns, network payloads) because it's fast — AES-NI hardware acceleration makes it nearly zero-overhead. Use asymmetric encryption for key exchange, digital signatures, and small payloads (e.g., TLS handshake, JWT signing). Never roll your own: use established libraries like Java's javax.crypto with GCM mode for authenticated encryption. In real systems, the algorithm is rarely the weakest link — key management and protocol misuse are.
Encryption ≠ Authentication
AES-CBC encrypts data but does not prevent tampering. Always use an authenticated mode like AES-GCM or append a MAC to detect ciphertext manipulation.
Production Insight
A payment gateway used AES-ECB to encrypt credit card numbers — identical blocks produced identical ciphertext, leaking card prefixes and BIN ranges.
The security audit flagged 'repeated ciphertext blocks' as a critical finding; attackers could infer card issuer and approximate account length.
Rule: never use ECB mode for any data with repeated patterns — always use GCM or CBC with a random IV.
Key Takeaway
AES-256-GCM is the default for symmetric encryption in production — authenticated, fast, and hardware-accelerated.
RSA is for key exchange and signatures, not for encrypting large payloads — use hybrid encryption (RSA + AES).
Key management is harder than algorithm selection: rotate keys, use a KMS, and never hardcode secrets.
thecodeforge.io
Encryption Algorithms in Production: AES, RSA, ECC
Encryption Algorithms Explained
DES and 3DES: Why 56 Bits Gets You Fired in 2026
DES the Data Encryption Standard was standardised by NIST in 1977. Its fatal flaw isn't the algorithm design itself, it's the key size: a mere 56 effective bits. With 2^56 possible keys (roughly 72 quadrillion combinations), that sounds enormous until you realise dedicated hardware can now exhaust the entire keyspace in hours, not days. The EFF's Deep Crack machine broke DES in 22 hours back in 1998 on 1998 hardware. Today, with a modest budget for cloud GPU instances, you're talking minutes. Forget it.
3DES (Triple DES) was the duct-tape fix: apply DES three times with different keys, effectively getting 112 bits of security. It worked as a stopgap and you'll still find it in payment processing systems that haven't been migrated, a stark reminder of PCI DSS's glacial pace (they only formally deprecated 3DES for new implementations in 2023). But 3DES is slow three cipher passes per block and its 64-bit block size creates a birthday attack vulnerability called SWEET32. Once you encrypt roughly 32GB of data under the same key, the birthday bound means you're likely to have duplicate plaintext blocks, allowing certain attacks. In a high-throughput API, you can hit that ceiling in a single day.
Don't use either in new code. Ever. If you're maintaining legacy code that uses them, that migration ticket is a P1 security item, not a 'nice to have'. Treat it like a critical SQL injection vulnerability. The technical debt is immense, and the risk is unacceptable.
Here's the painful part: migrating legacy encryption isn't just changing a cipher string. You need to identify all encrypted columns, decrypt with old key, re-encrypt with new, and rotate credentials all without downtime. We did it for a healthcare API using a dual-write strategy: write new records with AES-GCM, keep reading old records with 3DES, then backfill during off-peak hours. Took six months. Worth every minute.
Using 'DES/ECB/PKCS5Padding' on structured data like credit card numbers or user IDs means identical plaintexts produce identical ciphertexts. An attacker querying your encrypted column can detect which users share the same password hash equivalent without ever breaking the encryption. ECB mode is encryption theatre. If you see it in a codebase, treat it as a confirmed vulnerability, not a code smell. The same applies to AES-ECB.
Production Insight
One team encrypted all PII with DES/ECB because 'it was the default'. A penetration tester cracked 90% of SSNs in 4 hours by matching ciphertext patterns.
The fix: change to AES/GCM/NoPadding, re-encrypt all data, rotate keys.
Rule: If your encryption mode is ECB, you have no encryption you have obfuscation.
Key Takeaway
DES is broken since 1998 (EFF Deep Crack). 3DES is vulnerable to SWEET32 after ~32GB.
Use AES-256-GCM for all symmetric encryption. Never use ECB mode.
If you find DES/3DES in code, it's a P1 security incident not a refactoring task.
Is your data encrypted with DES or 3DES?
IfYou're writing new code
→
UseStop. Use AES-256-GCM or ChaCha20-Poly1305. Never DES/3DES.
IfLegacy 3DES data exists, < 32GB per key
→
UsePriority migration. Map dual-write strategy and backfill.
UseTreat as confirmed vulnerability. Schedule P1 ticket.
AES-GCM: The Workhorse for Modern Confidentiality and Integrity
AES (Advanced Encryption Standard) has been the cryptographic gold standard since NIST selected Rijndael in 2001. It supports 128, 192, and 256-bit keys and operates on fixed 128-bit blocks. The algorithm itself is robust; the trap lies almost exclusively in the mode of operation.
AES-ECB (Electronic Codebook) is what you use if you want your encryption to actively, and literally, leak information about your data. It encrypts each block independently. If you encrypt two identical blocks of data, you get two identical ciphertexts. This reveals patterns. AES-CBC (Cipher Block Chaining) is better; it's deterministic encryption for confidentiality. However, it only provides confidentiality. It doesn't tell you if the ciphertext was tampered with. This is where padding oracle attacks (POODLE, Lucky 13) exploit weaknesses. If an attacker can make your server reveal whether padding is correct or not, they can often decrypt arbitrary messages. Modern systems demand authenticated encryption, and that's where AES-GCM shines.
AES-GCM (Galois/Counter Mode) is what you should be using for symmetric encryption. It's an AEAD (Authenticated Encryption with Associated Data) mode, meaning it guarantees both confidentiality and integrity. If someone flips a single bit in your ciphertext, GCM decryption throws a javax.crypto.AEADBadTagException instead of silently handing you corrupted plaintext. That's not a nice-to-have; it's the difference between detecting an attack and processing fraudulent data. For databases, file encryption, or any data-at-rest scenario where you need to trust the data hasn't been modified, AES-256-GCM is your go-to.
GCM has one critical footgun:never reuse a nonce (Number Used Once) under the same key. Nonce reuse doesn't just weaken GCM; it catastrophically collapses its security. An attacker who observes two ciphertexts encrypted with the same key and nonce can XOR them together to cancel out the keystream and recover the plaintext of both messages. This has happened in real-world systems, notably in the Azure cloud. Always generate nonces with a cryptographically secure random number generator (SecureRandom in Java). Prepend the nonce to the ciphertext, and derive it from the blob during decryption. Never generate it from a counter you're storing in a database without robust distributed coordination, as even a simple failover can cause counter resets and collisions.
Then there's AAD Associated Data. Both AES-GCM and ChaCha20-Poly1305 support it, and you should use it. AAD is data that's not encrypted but is authenticated. Bind metadata (user ID, record type, timestamp) to the ciphertext. If an attacker copies an encrypted blob from one user's record to another's, the AAD mismatch causes decryption to fail. It's free, requires no extra storage, and catches an entire class of semantic attacks that pure ciphertext encryption misses.
And here's a trap I've seen in practice: someone implemented AES-GCM with nonce derived from a database sequence. When the DB was restored from backup, the sequence reset and boom, nonce reuse. They encrypted 200K records before noticing. The fix was using random nonces and key versioning. The lesson: never derive nonces from anything restartable.
Performance-wise, AES-GCM on modern x86 servers with AES-NI can encrypt at 1+ GB/s per core. Without AES-NI, throughput drops to 50-100 MB/s comparable to ChaCha20's software speed. That's why ChaCha20 exists.
Production Trap: Nonce Reuse Destroys GCM Security Completely
I saw a team implement AES-GCM with a nonce derived from a database auto-increment ID. When they restored a backup and the ID counter reset to a previous value, they started reusing nonces for new data encrypted under the same key. Two messages encrypted with the same key+nonce in GCM can be XORed together to recover both plaintexts the encryption is completely broken, not merely weakened. Always generate nonces with SecureRandom. Never derive them from any predictable or resettable source.
Production Insight
A cloud backup tool reused nonces across restorations because of a counter reset. Millions of records became decryptable by the attacker.
Always generate nonces with SecureRandom. Never use auto-increment IDs or timestamps.
The AEADBadTagException is your friend log it, alert on it, never ignore it.
Key Takeaway
AES-GCM provides both confidentiality and integrity (tamper detection).
Never reuse a nonce under the same key it collapses GCM security.
Use random nonces, prepend to ciphertext. Always version your keys.
Choosing between AES-GCM and ChaCha20-Poly1305
IfYour platform x86-64 with AES-NI? (check /proc/cpuinfo | grep aes)
UseUse ChaCha20-Poly1305 faster in software, constant time.
IfYou need FIPS 140-2/140-3 compliance?
→
UseUse AES-GCM. ChaCha20 not yet in FIPS modules.
IfProtocol design from scratch, want simplicity?
→
UseChaCha20-Poly1305: harder to get wrong, constant-time by design.
IfExisting codebase with AES-GCM but hitting performance without HW acceleration?
→
UseSwitch to ChaCha20-Poly1305 for that target.
ChaCha20-Poly1305: The AEAD Cipher When AES-NI Isn't Available
AES-GCM is the default choice for symmetric encryption on modern server hardware. But that qualifier 'modern server hardware' matters more than most engineers realize. AES-GCM's speed depends on AES-NI (AES New Instructions), a set of CPU instructions available on x86-64 processors since ~2010 and on newer ARM chips (ARMv8 Cryptography Extensions). Without AES-NI, AES-GCM falls back to a software implementation that is dramatically slower we're talking 10-20x slower, not 10-20% slower.
This matters for: mobile devices (older Android phones, especially ARMv7 devices without crypto extensions), embedded systems and IoT devices with limited CPU, cloud instances on non-x86 architectures (Graviton ARM instances are fast for AES if they have extensions, but not all do), and any environment where you can't guarantee hardware acceleration.
ChaCha20-Poly1305 was designed by Daniel J. Bernstein specifically to be fast in software without any hardware acceleration. It's a stream cipher (ChaCha20) combined with a MAC (Poly1305), giving you the same AEAD guarantee as AES-GCM: confidentiality plus integrity in one operation. Google adopted it for HTTPS in 2014 after measuring that it outperformed AES-GCM on Android devices by a significant margin. It's now in TLS 1.3 as a standard cipher suite, used by WireGuard, SSH, and Android's file-based encryption.
Key differences from AES-GCM: - ChaCha20 uses a 256-bit key and 96-bit nonce (same nonce size as GCM). - Poly1305 produces a 128-bit authentication tag (same as GCM's tag). - The nonce reuse rule is identical: never reuse a nonce under the same key. The consequences are similar keystream reuse allows plaintext recovery. - ChaCha20 has a simpler, more constant-time-friendly design. AES has known cache-timing vulnerabilities in software implementations; ChaCha20 doesn't use table lookups, so it's naturally resistant to cache-timing attacks.
When to choose which: - AES-256-GCM: default for server-side Java on x86-64 with AES-NI. Fastest option with hardware support. - ChaCha20-Poly1305: mobile clients, embedded systems, ARM without crypto extensions, or when you want a cipher with a simpler constant-time profile. Also preferred if you're building a protocol from scratch and want to avoid AES's complexity. - In Java: ChaCha20-Poly1305 is available since Java 11 (ChaCha20-Poly1305 transformation in JCA). Bouncy Castle also provides it.
A real-world data point: an IoT firmware update service using AES-GCM on ARM Cortex-M0 chips without AES-NI took 200ms per packet to decrypt. Switching to ChaCha20-Poly1305 brought it down to 15ms. That's the difference between a usable product and a brick.
Both AES-GCM and ChaCha20-Poly1305 support Associated Data (AAD) data that isn't encrypted but is authenticated. Use it to bind metadata (user ID, record type, timestamp) to the ciphertext. If an attacker copies an encrypted blob from one user's record to another's, the AAD mismatch causes decryption to fail. It's free, requires no extra storage, and catches an entire class of attacks that pure ciphertext encryption misses.
Production Insight
An IoT firmware update service used AES-GCM on ARM Cortex-M0 chips without AES-NI. Decryption took 200ms per packet, causing timeouts.
Switched to ChaCha20-Poly1305. Decryption dropped to 15ms per packet.
Rule: Always check for AES-NI support. If absent, ChaCha20 is your tool.
Key Takeaway
ChaCha20-Poly1305 is as secure as AES-GCM but faster in software without hardware acceleration.
Use it for mobile, IoT, or any platform without AES-NI.
Nonce reuse rules apply identically: never reuse a nonce under the same key.
RSA: The Unsung Hero of Key Exchange, a Villain in Direct Encryption
RSA solves a problem that symmetric encryption (like DES and AES) can't: secure key distribution. With symmetric encryption, both parties need the same secret key but how do you securely share that key in the first place? You can't encrypt it, because you don't have a shared key yet. RSA (Rivest Shamir Adleman, 1977) breaks this deadlock with a mathematically linked key pair: a public key you can share with the world, and a private key that never leaves your server.
The math rests on the difficulty of factoring the product of two large prime numbers. If I multiply two 2048-bit primes together, the resulting number is your RSA modulus. Deriving the private key from the public key requires factoring that modulus back into its primes a problem that has no known efficient classical algorithm. Quantum computers with sufficient qubits could break this via Shor's algorithm, which is why NIST is actively standardizing post-quantum replacements.
Here's the production reality many engineers miss: RSA is slow. RSA-2048 encryption is roughly 1000x slower than AES-256. You never, ever use RSA to encrypt bulk data. You use it to encrypt a randomly generated AES session key, then use that AES key for the actual payload. This is precisely what TLS does during its handshake. RSA-OAEP (Optimal Asymmetric Encryption Padding) is the padding scheme you must use. PKCS#1 v1.5 is vulnerable to Bleichenbacher's padding oracle attack a classic exploit that has broken real-world TLS implementations and is still found in legacy systems. Don't be that team.
Another trap: key size. Since JDK 8u301 and JDK 11.0.11, the JVM's default security policy disallows RSA keys below 1024 bits, throwing InvalidKeyException at runtime. NIST has considered 512-bit RSA broken since 2010. Use 2048-bit minimum for anything active; 4096-bit for certificate authorities or keys with 10+ year lifetimes. If you're still using RSA-1024 in production today, it's a ticking compliance bomb.
And one more thing: if you're using RSA for signing, use PSS padding, not PKCS#1 v1.5. The latter has known weaknesses for signature schemes too. Most crypto libraries default to PSS these days, but double-check.
Performance comparison: RSA-2048 encrypt is ~10,000 ops/sec on a modern core, while AES-256-GCM hits 1M+ ops/sec. That's why hybrid encryption is non-negotiable.
Production Trap: RSA Key Size Below 2048 Bits Fails in Modern JVMs
Since JDK 8u301 and JDK 11.0.11, the JVM's default security policy disallows RSA keys below 1024 bits and will throw InvalidKeyException. Some older JVMs allowed 512-bit keys, which NIST considers broken since 2010. Use 2048-bit minimum for anything active; 4096-bit for certificate authorities or keys with 10+ year lifetimes.
Production Insight
Many teams deploy RSA-1024 keys in TLS certificates because 'it still works'. Then penetration testers flag them as 'medium' severity and compliance auditors demand immediate replacement. RSA-1024 is effectively broken by state-level actors.
Rule: Use RSA-2048 minimum. Migrate to ECDSA or ML-KEM for future-proofing.
Key Takeaway
RSA is for key encapsulation, not bulk encryption.
Use OAEP padding, never PKCS#1 v1.5.
RSA-2048 is the minimum today. Prefer ECDHE for forward secrecy.
RSA vs ECC for key exchange and signatures
IfYou need a mature, widely supported key exchange for legacy TLS
→
UseUse RSA-2048 with OAEP for key encapsulation. But prefer ECDHE.
IfYou want forward secrecy and smaller keys
→
UseUse ECDHE with P-256 or X25519. No RSA key exchange.
IfDigital signatures for certificates
→
UseUse ECDSA P-256 or Ed25519. Much smaller signature than RSA-2048.
IfCompliance requires FIPS 140-2/140-3
→
UseRSA is allowed but ECDSA with P-256 is also FIPS-approved.
IfPost-quantum migration starting now
→
UseUse hybrid: RSA+ML-KEM or ECDH+ML-KEM. Plan to drop RSA by 2030.
Elliptic Curve Cryptography (ECC): Smaller Keys, Same Security, Less Headroom
Elliptic Curve Cryptography (ECC) is the modern evolution of asymmetric encryption. It offers equivalent security to RSA but with much smaller key sizes a 256-bit ECC key is roughly equivalent to a 3072-bit RSA key. That means faster operations, less bandwidth, and smaller signatures. ECC is the backbone of modern TLS (ECDHE, ECDSA), Bitcoin (secp256k1), and SSH (Ed25519).
There are two main ECC primitives you'll encounter
ECDH (Elliptic Curve Diffie-Hellman) key exchange, used in TLS 1.3 for perfect forward secrecy.
ECDSA (Elliptic Curve Digital Signature Algorithm) for signing and verification.
Ed25519 and X25519 are the modern, safer implementations based on Curve25519, designed by Daniel J. Bernstein to be constant-time and avoid common implementation pitfalls.
Production traps: - Curve selection matters: P-256 (secp256r1) is the widely interoperable default. P-384 gives slightly more headroom but is often overkill. Avoid curves like P-224 or secp160k1 outside very specialized contexts. - ECDSA requires a secure random nonce per signature. Reusing a nonce (even two signatures) reveals the private key. This has happened in real products: Sony's PlayStation 3 used a static k value, allowing attackers to extract the signing key. - ECDH with static keys: Without ephemeral keys, you lose forward secrecy. Use ECDHE (ephemeral ECDH) for every session. - Ed25519 is not yet widely accepted for all use cases (e.g., some FIPS modules exclude it). But it's the safest choice for new protocols due to its simple, constant-time design.
Performance: ECDH P-256 key agreement is about 10x faster than RSA-2048 key encapsulation. ECDSA verify is also faster than RSA verify. This matters for high-traffic APIs and IoT devices.
If an ECDSA signature nonce (k) is reused, an attacker can compute your private key directly. This happened with Sony's PS3 firmware signing. Always ensure your crypto library generates fresh random nonces. Ed25519 avoids this issue entirely by deterministically deriving the nonce.
Production Insight
An IoT device used ECDSA with a static nonce because the RNG was not seeded. All signatures shared the same k value, exposing the private key.
The fix: update firmware to use a hardware TRNG for nonce generation or switch to Ed25519.
Rule: Never assume your RNG is secure. Use modern, deterministic signing schemes like Ed25519.
Key Takeaway
ECC gives equivalent security to RSA with much smaller keys.
Use ECDHE for key exchange, Ed25519 for signatures.
Avoid ECDSA if you can't guarantee secure random nonces.
RSA vs ECC for asymmetric operations
IfYou need key exchange with forward secrecy
→
UseUse ECDHE with P-256 or X25519. Avoid RSA key exchange.
IfYou need digital signatures, smallest size possible
→
UseUse Ed25519. 64-byte signatures, fast verification.
IfYour ecosystem requires FIPS 140-2 compatibility
→
UseUse ECDSA P-256. FIPS-approved, widely supported in hardware.
IfYou're dealing with legacy systems that only support RSA
→
UseUse RSA-2048 with OAEP, but plan to add ECDH for new clients.
Post-Quantum Cryptography: Why Your RSA Keys Won't Survive the 2030s
Post-quantum cryptography (PQC) is the field of cryptographic algorithms designed to be secure against both classical and quantum computers. Shor's algorithm, when run on a sufficiently large fault-tolerant quantum computer, can break RSA and ECC by solving the underlying hard problems (integer factorization and discrete logarithm) in polynomial time. That's not a theoretical concern anymore NIST has been running a multi-year standardization process, and in 2024 they finalized the first set of standards.
The two main algorithms you need to know
ML-KEM (CRYSTALS-Kyber): Key encapsulation mechanism, replacing ECDH and RSA key exchange. Uses lattice-based cryptography. Provides 128-bit security classically and ~64-bit against quantum attacks.
ML-DSA (CRYSTALS-Dilithium): Digital signature algorithm, replacing ECDSA and RSA signatures. Slightly larger signatures than ECDSA but still practical.
FN-DSA (FALCON): Alternative signature scheme with smaller signatures but more complex implementation.
SLH-DSA (SPHINCS+): Stateless hash-based signatures, large but with high confidence in security.
When should you migrate? Don't wait for a quantum computer to exist. The 'harvest now, decrypt later' threat is real: attackers are already collecting encrypted traffic that will be decryptable once quantum computers become available. For data with long-term sensitivity (SSNs, medical records, state secrets), you should start migrating now using hybrid solutions: combine traditional (RSA/ECDH) with PQC (ML-KEM) so that even if one is broken, the other still holds.
Production reality in 2026: - Most cloud providers (AWS KMS, Google Cloud KMS) already support hybrid modes with ML-KEM. - TLS 1.3 has experimental hybrids (X25519+ML-KEM). - OpenSSH 9.x supports ML-KEM key exchange. - Java 21+ has limited test implementations; expect full support by Java 25 or 26. - Key sizes: ML-KEM-768 ciphertext ~1KB, ML-DSA-44 signature ~3KB (vs 64 bytes for Ed25519). That's a bandwidth cost.
Your action plan: - Enable hybrid key exchange in TLS wherever possible (e.g., OQS OpenSSL fork). - For long-term data encryption, use envelope encryption with hybrid wrapping (RSA + ML-KEM). - Monitor NIST and your cloud provider's announcements. By 2028, expect default PQC support. - Don't panic: classical crypto will coexist for another decade. But start testing now.
Encrypted traffic captured now can be stored and decrypted in 10-15 years.
Data with long-term sensitivity (SSN, medical records, state secrets) is at risk.
Hybrid encryption (classical + PQC) protects against both current and future adversaries.
Start testing PQC now even if you don't deploy it. Understand the performance impact.
Cloud KMS providers (AWS, GCP) already support hybrid PQC modes in 2026.
Production Insight
Major cloud providers now support hybrid PQC key exchange. AWS KMS added ML-KEM in 2025.
The bandwidth cost is real: ML-KEM-768 ciphertext ~1KB, ML-DSA-44 signature ~3KB.
Rule: Start hybrid migration for long-lived data now. Don't wait for the quantum computer.
Key Takeaway
Post-quantum cryptography (ML-KEM, ML-DSA) is standardized.
Use hybrid (classical + PQC) for future-proofing.
Harvest-now-decrypt-later is a real threat for sensitive long-lived data.
Post-quantum migration priority
IfData must remain secret for 10+ years (medical, gov, financial)
→
UseStart hybrid PQC migration now. Use ML-KEM + AES-256-GCM envelope.
IfTLS certificates with 5+ year validity
→
UseUse hybrid certificates with ML-DSA alongside ECDSA/RSA.
IfYou're building a new protocol or system today
→
UseDesign for hybrid from day one. Use libraries that support PQC (OQS, Bouncy Castle).
IfData is short-lived (session keys, ephemeral comms)
→
UseNo immediate need, but monitor NIST standards and plan migration timeline.
Ciphertext Length and Padding: Why Your Encrypted Data Explodes in Size
You encrypted 10 bytes and got back 48. Did something go wrong? No. You just hit the wall of block cipher padding and AEAD overhead. Every encryption algorithm has an expansion tax, and ignoring it is how you overflow a database column at 2 AM.
Block ciphers like AES only encrypt fixed-size blocks — 16 bytes each. If your plaintext isn't a perfect multiple of 16, padding schemes like PKCS#7 fill the gap. That means even 1 byte of plaintext becomes a full 16-byte block plus authentication tag. AEAD modes add another 16 bytes for the tag. Suddenly your 10-byte credit card PAN costs 48 bytes on disk.
Stream ciphers like ChaCha20 don't pad, but they still tack on a Poly1305 tag. The trade-off is predictable expansion vs. complexity. RSA is worse — OAEP padding forces your payload to at least 42 bytes smaller than your key size. A 2048-bit RSA key encrypts a max of 190 bytes, not 256.
The fix: know your cipher's overhead before you design your schema. Always buffer at least 64 bytes of overhead per encrypted field. And never use ECB mode — it doesn't pad visibly, but it leaks data patterns. Learn from our S3 bucket incident.
Never assume ciphertext == plaintext size. Always compute max expansion before defining database column lengths. A VARCHAR(50) will choke on a 44-byte ciphertext.
Key Takeaway
Every encryption mode has a fixed overhead. Calculate it upfront, or your database migration will fail in prod.
Attacks and Countermeasures: The Real Threats That Keep Me Up at Night
You don't get hacked because someone brute-forced AES-256. You get hacked because you reused a nonce, used ECB mode on structured data, or forgot to authenticate your ciphertexts. Let's talk about the attacks that actually burn production systems.
Nonce reuse is the silent killer. In AES-GCM, reusing the IV with the same key lets an attacker recover the authentication key and forge messages. ChaCha20-Poly1305 has the same vulnerability. One reused nonce and your integrity guarantee is gone. The fix: use a 96-bit random nonce generated by SecureRandom. Never use a counter or timestamp without a distinct key.
Padding oracle attacks are still alive in 2026. If your API returns different errors for valid vs. invalid padding, attackers can decrypt anything byte by byte. CBC mode is the usual culprit. The countermeasure: use AEAD modes (GCM, ChaCha20-Poly1305) that authenticate the ciphertext. Or implement constant-time validation on decryption.
Timing attacks leak key material through measurable response differences. Even a nanosecond variation across thousands of requests reveals bits. Constant-time comparisons for MACs and signatures are non-negotiable. Java's MessageDigest.isEqual() is constant-time — use it. Don't write your own equals().
Side-channel attacks? If an attacker has physical access, you've already lost. But they can still extract keys from memory dumps. Use the JCA provider's SecureRandom for key generation to limit exposure in swap.
ConstantTimeMacVerification.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// io.thecodeforge — dsa tutorialimport javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.security.MessageDigest;
import java.util.Arrays;
publicclassConstantTimeMacVerification {
publicstaticvoidmain(String[] args) throwsException {
// Simulate computing and verifying a HMAC-SHA256 tagbyte[] keyMaterial = newbyte[32];
new java.security.SecureRandom().nextBytes(keyMaterial);
SecretKeySpec hmacKey = newSecretKeySpec(keyMaterial, "HmacSHA256");
String message = "Encrypt then MAC. Always.";
Mac mac = Mac.getInstance("HmacSHA256");
mac.init(hmacKey);
byte[] computedTag = mac.doFinal(message.getBytes());
// Attacker provides this tagbyte[] attackerSuppliedTag = computedTag.clone();
attackerSuppliedTag[0] ^= 0x01; // flip one bit to simulate forged tag// Constant-time comparison — never use Arrays.equals() hereboolean isValid = MessageDigest.isEqual(computedTag, attackerSuppliedTag);
System.out.println("Tag valid? " + isValid);
}
}
Output
Tag valid? false
Senior Shortcut:
Always authenticate your ciphertext. Encrypt-then-MAC is the only ordering that prevents padding oracle attacks. If your library does it automatically (GCM, Poly1305), fine — never wrap a non-AEAD cipher with your own MAC.
Key Takeaway
Nonce reuse and padding oracles are the most common production crypto failures. Use AEAD modes and constant-time comparisons to block them.
Real-World Cryptography: Where the Rubber Meets the Rot13
Theory is cheap. Production is where encryption earns its keep. You're not encrypting random byte streams — you're protecting TLS handshakes, database columns, JWT tokens, and cloud storage buckets. Each has different constraints. TLS uses ephemeral ECDHE for forward secrecy. Database encryption uses AES-GCM-SIV to resist nonce reuse when a DBA fat-fingers a backup restore. JWT signing? HMAC-SHA256 or EdDSA — never RSA directly, because your token payload isn't a 3KB email.
Cloud providers encrypt everything at rest with envelope encryption: a DEK encrypted by a KEK in HSM. That means you never touch the master key. AWS KMS, GCP Cloud KMS, Azure Key Vault — they all work this way. Your code calls Encrypt once per object, not once per byte. The DEK rotates without re-encrypting petabytes. Build like that.
Mobile apps use HPKE (Hybrid Public Key Encryption) to encrypt small payloads without TLS overhead. Signal Protocol uses X3DH + AES-GCM. WhatsApp uses the same. Real-world crypto is about picking the right tool for the job, not the one that made you feel smart in a textbook.
Always use a KMS to wrap DEKs — never store wrapped keys in the same bucket as ciphertext without proper IAM boundaries.
Key Takeaway
Envelope encryption scales; direct encryption of large data with a master key is a rookie mistake.
Real-World Applications of Cryptography: Beyond the Tunnel
Stop thinking of crypto as just HTTPS. Authentication, integrity, non-repudiation, and confidentiality happen everywhere. Code signing ensures your CI/CD pipeline doesn't push a backdoor. Git commit signing with GPG or SSH keys proves you, not a bot, pushed that tag. Cryptographic hashes verify firmware images in IoT devices — one bad SHA-256 check and a smart bulb becomes a DDoS node.
Zero Trust architectures rely on mTLS — every service proves its identity with a certificate signed by an internal CA. No VPN tunnel, no implicit trust. Kubernetes uses this for pod-to-pod communication with SPIFFE identities. The key insight: crypto gives you verifiable identity without shared secrets. That's why SSH keys replaced passwords for server access.
Blockchain uses ECDSA for transaction signing — not because it's cool, but because recovery of the public key from the signature allows verification without storing the key. That's a real optimization. Your bank uses RSA-2048 to sign SWIFT messages. Your phone uses AES-256 to encrypt the secure enclave. The list is endless because crypto is not a feature — it's infrastructure.
For internal artifact signing, use Ed25519 — faster and smaller signatures than RSA-2048 with equivalent security.
Key Takeaway
Crypto is the trust layer for identity, integrity, and authenticity — not just encryption.
Why DSA Exists: Digital Signatures, Not Secrecy
Most engineers confuse DSA with encryption. It isn't. The Digital Signature Algorithm authenticates origin and integrity — it proves who sent a message and that it wasn't tampered with. DSA uses a global public-key infrastructure: three parameters (p, q, g) shared across all users, plus a private key x and public key y. Signing requires a random nonce k; reusing k once leaks your private key entirely. Verification recovers a value r from the signature and checks it against the signer's public key. Unlike RSA, DSA cannot encrypt — it only signs. This separation forces architects to pair DSA with a symmetric cipher for confidentiality, a pattern called hybrid cryptosystems. The Federal Information Processing Standard (FIPS 186) mandates DSA for U.S. government digital signatures, but ECDSA (elliptic curve variant) now dominates because it halves key sizes at equivalent security levels.
Never reuse the k nonce across signatures — it mathematically exposes your private key. Always use a CSPRNG like SecureRandom.
Key Takeaway
DSA is for authentication, not encryption; pair it with AES for confidentiality.
How DSA Works: The Four-Step Dance of Modular Arithmetic
DSA's security rests on the discrete logarithm problem: given g^x mod p, finding x is infeasible for sufficiently large primes. The algorithm runs in four steps. First, parameter generation: choose a prime p (1024–3072 bits), a prime q dividing p-1 (160–256 bits), and a generator g = h^((p-1)/q) mod p. Second, key generation: pick random private key x in [1, q-1], compute public key y = g^x mod p. Third, signing: generate random k, compute r = (g^k mod p) mod q, compute s = k^(-1) (SHA256(message) + xr) mod q. Fourth, verification: compute w = s^(-1) mod q, u1 = SHA256(message)w mod q, u2 = rw mod q, v = (g^u1 * y^u2 mod p) mod q — accept if v equals r. The modular inversion in signing (k^(-1)) is the computational bottleneck; precomputation of k and its inverse speeds production systems significantly.
DSASteps.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
// io.thecodeforge — dsa tutorialimport java.math.BigInteger;
publicclassDSASteps {
publicstaticvoidmain(String[] args) {
BigInteger p = new BigInteger("898846567431157953864652595394512366808988489471153286367150405788663379027504815663542386612037680105600569399356966788293948844072083112464237195137569542245315795733958765167787106602363113136321393606421057822318848916587346997175181835116606291843589786854775390654520057727415504822862223893807866197468521"); // 1024-bitBigInteger q = new BigInteger("1361129467683753853853498429727072845823"); // 160-bitBigInteger g = new BigInteger("12345"); // simplifiedBigInteger x = new BigInteger("98765"); // private keyBigInteger y = g.modPow(x, p); // public keySystem.out.println("y bits: " + y.bitLength());
}
}
Output
y bits: 1024
Why p and q:
The subgroup q prevents index-calculus attacks; p protects against Number Field Sieve. Both are mandatory.
Key Takeaway
DSA verification is a double modular exponentiation; performance degrades linearly with key size.
DSA vs. RSA: When Signature Size and Performance Matter
DSA signatures are fixed-size (two 256-bit integers for 128-bit security, total 512 bits), while RSA signatures grow with key size (342 bytes for 3072-bit RSA). DSA's public key generation is faster — one modular exponentiation versus RSA's need for two large primes. But DSA verification requires two exponentiations, making it slower than RSA verification's single exponentiation. DSA's critical weakness: it demands high-quality randomness for every signature. A broken RNG — common in IoT devices and VMs — produces collisions that leak the private key. RSA avoids this by deterministically signing with PKCS#1 v1.5 or PSS padding. Modern systems favor ECDSA, which shrinks signatures to 64 bytes for 128-bit security and runs on constrained hardware. The U.S. government mandates DSA for legacy compliance, but the industry standard is now EdDSA (Ed25519), offering deterministic signing, faster verification, and side-channel resistance.
NIST SP 800-186 deprecates DSA key sizes below 2048 bits. Move to EdDSA for new systems.
Key Takeaway
DSA beats RSA on signature size and key generation speed but loses on verification speed and randomness requirements.
Primary Terminologies: The Vocabulary of Digital Signatures
Understanding DSA requires grasping a few key terms. First, a digital signature is a mathematical scheme for verifying the authenticity and integrity of digital messages or documents, akin to a handwritten signature but far more secure. The public key is shared openly and used by anyone to verify a signature, while the private key is kept secret and used by the signer to create the signature. Hashing is the process of converting a message into a fixed-length string (hash) using a algorithm like SHA-256, which serves as the message's fingerprint. Modular arithmetic underpins all operations, where calculations wrap around a prime number modulus (p). Finally, signature generation and signature verification are the two core operations: the former produces a signature pair (r, s), and the latter checks it against the original message and public key. Without these building blocks, DSA's security guarantees collapse into meaningless math.
Never confuse hash length with security. Using SHA-1 (160-bit hash) with DSA can lead to collisions; always pair DSA with SHA-256 or higher.
Key Takeaway
Know your vocabulary: public key, private key, hash, and modulus are non-negotiable for DSA.
Advantages of DSA: Why It's Still in Your Toolbelt
DSA has specific advantages that keep it relevant despite competition from ECDSA and EdDSA. First, it's standardized and battle-tested: adopted by NIST in 1994, DSA has undergone decades of cryptanalysis, making it a known quantity for compliance-heavy industries like government and finance. Second, signature generation is fast on hardware without acceleration, as it uses modular exponentiation that older CPUs handle efficiently. Third, DSA signatures are relatively compact: a 1024-bit key produces a 320-byte signature (40 bytes for r and s each), which is smaller than RSA signatures of equivalent security. Fourth, it supports forward secrecy when used in protocols like DHE-DSS, meaning past signatures remain valid even if a long-term key is compromised. Finally, DSA is patent-free, avoiding licensing fees that plagued other algorithms. For systems where simplicity and auditability trump bleeding-edge performance, DSA remains a solid choice.
DSA requires a unique random k value per signature. Reusing k leaks your private key instantly—always use a cryptographically secure RNG.
Key Takeaway
DSA shines in compliance contexts and where hardware acceleration is limited.
Disadvantages of DSA: Where It Falls Short
Despite its strengths, DSA has notable drawbacks. First, performance is asymmetric: signature verification is slower than RSA and much slower than ECDSA, making it unsuitable for high-throughput verification scenarios like large-scale certificate validation. Second, key size limitations: DSA's security correlates to its modulus size (p), but it caps out around 3072 bits (128-bit security), whereas ECC can match that with 256-bit keys. Third, the randomness requirement is a critical weakness: DSA mandates a unique random nonce (k) per signature; if the random number generator fails or k is reused, the private key can be reconstructed mathematically—a disaster exposed in Sony's PS3 hack. Fourth, DSA has no built-in encryption capability; it only signs, so you must pair it with a separate encryption algorithm like RSA or ElGamal for messaging. Finally, post-quantum vulnerability: like RSA, DSA is broken by Shor's algorithm once quantum computers scale. For new systems, ECDSA or EdDSA usually outperform DSA in both speed and security margin.
DSADrawback.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// io.thecodeforge — dsa tutorialimport java.security.*;
publicclassDSADrawback {
publicstaticvoidmain(String[] args) throwsException {
// Measure verification speedKeyPairGenerator gen = KeyPairGenerator.getInstance("DSA");
gen.initialize(1024);
KeyPair pair = gen.generateKeyPair();
Signature sig = Signature.getInstance("SHA256withDSA");
sig.initSign(pair.getPrivate());
sig.update("Hello".getBytes());
byte[] sign = sig.sign();
long start = System.nanoTime();
for (int i = 0; i < 1000; i++) {
sig.initVerify(pair.getPublic());
sig.update("Hello".getBytes());
sig.verify(sign);
}
long end = System.nanoTime();
System.out.println("Time per verify: " + (end - start)/1000 + " ns");
}
}
Output
Time per verify: 234567 ns
Production Trap:
If your RNG is broken, DSA signatures become a backdoor. Always use SecureRandom in Java and consider deterministic DSA (RFC 6979) to eliminate randomness issues.
Key Takeaway
DSA's randomness problem and slow verification make it risky for modern high-throughput systems.
● Production incidentPOST-MORTEMseverity: high
The DES That Leaked Every Customer SSN
Symptom
Penetration test revealed that all customer SSNs, credit card numbers, and PII fields were encrypted with single DES in ECB mode. Ciphertexts of identical plaintexts were identical, revealing frequency patterns across records.
Assumption
The team assumed that because they were using a 'standard' cipher (DES), it was secure. Nobody reviewed the cipher string itself.
Root cause
Copy-pasted code with 'DES/ECB/PKCS5Padding' from a 2004 Stack Overflow answer. No code review checked the cipher algorithm. Compliance scanning only checked that encryption existed, not what kind.
Fix
Changed the cipher string to 'AES/GCM/NoPadding'. Rotated all encryption keys. Re-encrypted all existing data with AES-256-GCM via AWS KMS using envelope encryption.
Key lesson
Never trust encryption without auditing the exact cipher string and mode.
Treat 'DES/ECB' as a confirmed vulnerability, not a code smell.
Use automated static analysis to flag weak ciphers in code reviews.
Production debug guideSymptom → Action for common encryption failures5 entries
Symptom · 01
javax.crypto.AEADBadTagException thrown during decryption
→
Fix
Check nonce reuse: are nonces generated from a predictable source like an auto-increment ID? Check data corruption: is the ciphertext intact? Check key version mismatch: does the stored key version match the key in KMS?
Symptom · 02
Decryption produces garbage or partial plaintext
→
Fix
Verify key and IV/nonce used match the ones during encryption. Ensure base64 encoding/decoding is consistent. Check padding: GCM uses no padding, CBC requires correct padding scheme.
Symptom · 03
TLS handshake fails with 'no common cipher suites'
→
Fix
List supported cipher suites: openssl ciphers -v. Ensure both sides support TLS 1.3+ and AEAD ciphers. Check for deprecated ciphers like 3DES or RC4 being disabled on server.
Symptom · 04
Performance degradation after enabling encryption
→
Fix
Profile if AES-NI is available: /proc/cpuinfo should show aes flag. If not, switch to ChaCha20-Poly1305. Check for repeated RSA operations: each RSA-2048 encrypt is ~1000x slower than AES. Use hybrid encryption.
Symptom · 05
Key rotation breaks existing ciphertexts
→
Fix
Add key version identifier to ciphertext format. Use envelope encryption: store wrapped DEK with ciphertext. When master key rotates, re-wrap DEKs, not re-encrypt data.
★ Quick Debug Cheat Sheet: Encryption IssuesFor on-call engineers encountering encryption problems. Run these commands to diagnose.
Ensure KMS key rotation keeps old versions active for decryption. Update key version in application config.
Key takeaways
1
Single DES with 56-bit keys can be brute-forced in minutes on consumer hardware—if you're still using DES or 3DES in 202 tracking, treat migration as a P1 security incident, not technical debt.
2
AES-GCM is the default production choice
authenticated encryption (AEAD) providing confidentiality and integrity in one pass, with AES-NI hardware acceleration reaching 1-2 GB/s per core on modern x86.
3
RSA is not for bulk data encryption—it's a trapdoor permutation for key exchange and signatures only; encrypting data directly with RSA is slow and vulnerable to padding oracle attacks like Bleichenbacher's.
4
ChaCha20-Poly1305 replaces AES when hardware acceleration is absent (mobile, IoT, older ARM); it's ~3x faster in software and equally secure, which is why Google uses it for Android and Chrome TLS.
5
The algorithm is rarely the weakest link—key management, protocol misuse, and copy-pasted cipher strings (like 'DES/ECB/PKCS5Padding') cause production breaches; always verify cipher strings in code review.
Common mistakes to avoid
7 patterns
×
Using AES-ECB mode on structured data
Symptom
Identical plaintext blocks produce identical ciphertexts, revealing patterns. An attacker can determine which encrypted values are the same.
Fix
Replace with AES-GCM. Never use ECB mode for any data with structure.
×
Nonce reuse in GCM or ChaCha20-Poly1305
Symptom
Two ciphertexts encrypted with same key and nonce can be XORed to recover plaintexts completely. No error until third decryption fails.
Fix
Always generate nonces with SecureRandom. Never derive from auto-increment IDs or timestamps.
×
Using RSA to encrypt bulk data directly
Symptom
Extremely slow performance (1000x slower than AES) and ciphertext size blowup. Key cannot encrypt data larger than key size.
Fix
Use RSA for key wrapping only. Generate an ephemeral AES key, encrypt data with AES-GCM, then RSA-encrypt the AES key.
×
Hardcoding encryption keys in source code
Symptom
Keys exposed in version control, accessible to all developers, and impossible to rotate without redeployment.
Fix
Use a KMS (AWS KMS, Vault) or environment variables with strict access control. Use envelope encryption with a data encryption key.
×
Not rotating keys regularly
Symptom
If a key is compromised, all data encrypted with that key is exposed. Compliance audits flag lack of rotation.
Fix
Implement a key rotation policy (e.g., every 90 days for master keys). Use versioned keys and re-wrap DEKs instead of re-encrypting all data.
×
Using deprecated ciphers (RC4, 3DES, DES)
Symptom
Numeric vulnerability scanners flag these as critical issues. PCI DSS compliance requires their removal.
Fix
Disable all deprecated ciphers in server config. Migrate to AES-GCM or ChaCha20-Poly1305. For TLS, use only TLS 1.2+ with AEAD suites.
×
Using static ECDSA nonce (k value)
Symptom
If k is reused, the private key can be calculated directly. Sony's PS3 signing key was extracted this way.
Fix
Always use a cryptographic RNG for ECDSA nonces. Better yet, use Ed25519 which derives nonces deterministically.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01JUNIOR
Explain the difference between symmetric and asymmetric encryption, and ...
Q02SENIOR
What is the most common misconfiguration you've seen with AES-GCM in pro...
Q03SENIOR
Why is RSA with PKCS#1 v1.5 padding considered dangerous? What should yo...
Q04SENIOR
Compare ECC and RSA for key exchange and signatures. When would you choo...
Q05SENIOR
What is post-quantum cryptography, and how do you recommend starting mig...
Q01 of 05JUNIOR
Explain the difference between symmetric and asymmetric encryption, and give a real-world example where both are used together.
ANSWER
Symmetric encryption uses the same key for encryption and decryption (e.g., AES). Asymmetric uses a public-private key pair (e.g., RSA). They are used together in TLS: the handshake uses asymmetric encryption (ECDHE) to exchange a symmetric session key, then the bulk data is encrypted with AES-GCM. This combines the security of asymmetric key exchange with the performance of symmetric encryption.
Q02 of 05SENIOR
What is the most common misconfiguration you've seen with AES-GCM in production? How would you fix it?
ANSWER
The most common mistake is nonce reuse. Teams often derive nonces from a database auto-increment ID or a timestamp, which can reset after backup restoration. The fix is to generate nonces using SecureRandom and prepend them to the ciphertext. Also, always use a key version prefix to support rotation.
Q03 of 05SENIOR
Why is RSA with PKCS#1 v1.5 padding considered dangerous? What should you use instead?
ANSWER
PKCS#1 v1.5 is vulnerable to Bleichenbacher's padding oracle attack. An attacker can send malformed ciphertexts to the server and, based on the error response, decrypt arbitrary messages. The fix is to use OAEP padding (RSA/ECB/OAEPWithSHA-256AndMGF1Padding) which is provably secure.
Q04 of 05SENIOR
Compare ECC and RSA for key exchange and signatures. When would you choose one over the other?
ANSWER
ECC offers equivalent security with much smaller key sizes (256-bit ECC ~ 3072-bit RSA). ECDHE provides forward secrecy, while RSA key exchange does not. ECDSA signatures are smaller and faster to verify. Choose ECC for new systems, especially mobile or IoT; RSA for legacy compatibility or FIPS compliance where ECC support is limited.
Q05 of 05SENIOR
What is post-quantum cryptography, and how do you recommend starting migration in 2026?
ANSWER
PQC algorithms resist attacks from both classical and quantum computers. The NIST standards are ML-KEM (key exchange) and ML-DSA (signatures). Start migration by using hybrid keys: combine RSA/ECDH with ML-KEM for key exchange and ECDSA with ML-DSA for signatures. Enable hybrid TLS cipher suites. For data at rest, use envelope encryption that wraps an AES key with both RSA and ML-KEM. The goal is to maintain compatibility while gaining quantum resistance.
01
Explain the difference between symmetric and asymmetric encryption, and give a real-world example where both are used together.
JUNIOR
02
What is the most common misconfiguration you've seen with AES-GCM in production? How would you fix it?
SENIOR
03
Why is RSA with PKCS#1 v1.5 padding considered dangerous? What should you use instead?
SENIOR
04
Compare ECC and RSA for key exchange and signatures. When would you choose one over the other?
SENIOR
05
What is post-quantum cryptography, and how do you recommend starting migration in 2026?
SENIOR
FAQ · 5 QUESTIONS
Frequently Asked Questions
01
Can I use AES-128 instead of AES-256?
Yes, AES-128 is still considered secure against classical attacks. However, AES-256 provides a larger security margin and is required for many compliance standards (e.g., FIPS 140-2 Level 3). The performance difference is negligible on hardware with AES-NI (only about 10-20% slower).
Was this helpful?
02
What happens if I accidentally reuse a nonce in AES-GCM?
Two ciphertexts encrypted with the same key and nonce can be XORed together. An attacker can then recover the keystream and decrypt both messages. This is catastrophic and silent no error is thrown until the third message tries to decrypt. Always use SecureRandom for nonces.
Was this helpful?
03
Is ChaCha20-Poly1305 as secure as AES-GCM?
Yes. Both provide authenticated encryption (AEAD) with 256-bit keys and 128-bit tags. ChaCha20-Poly1305 has a simpler, constant-time design that avoids cache-timing side channels. Google uses it for HTTPS on Android. The main reason to choose AES-GCM is hardware acceleration on x86-64 (AES-NI) and FIPS compliance.
Was this helpful?
04
How do I handle key rotation for encrypted data at rest?
Use envelope encryption: generate a unique data encryption key (DEK) for each record, encrypt the payload with the DEK, and then encrypt the DEK with a master key (KEK). When the KEK rotates, you only need to re-encrypt the DEKs (re-wrap), not the entire payload. Store the key version alongside the ciphertext.
Was this helpful?
05
Should I be worried about quantum computers breaking my encryption?
For data with a lifespan of less than 10 years, no immediate action is needed. But for long-lived data (medical records, government secrets), start hybrid migration now. Attackers are already collecting encrypted traffic for future decryption (harvest now, decrypt later). Enable hybrid TLS (X25519+ML-KEM) where possible.