Cryptography
Encryption
TLS
AES
Argon2
+3 more
Encryption Best Practices 2026: TLS 1.3, AES-256, Argon2 & Post-Quantum Readiness
Modern Cryptography Standards (2026)
| Use Case | Recommended Algorithm | Key Size | Status |
|---|---|---|---|
| Data in transit | TLS 1.3 | N/A (protocol) | Current standard |
| Symmetric encryption | AES-256-GCM | 256-bit | Current standard |
| Password hashing | Argon2id | N/A (hash) | OWASP recommended |
| Digital signatures | Ed25519 or ECDSA P-256 | 256-bit | Current standard |
| Key exchange | X25519 | 255-bit | Current standard |
| Hashing | SHA-256 or SHA-3 | 256-bit | Current standard |
| Post-quantum KEM | ML-KEM-768 (Kyber) | 768-bit | NIST finalized 2024 |
| Post-quantum signatures | ML-DSA-65 (Dilithium) | Level 3 | NIST finalized 2024 |
TLS 1.3 Configuration
What Changed in TLS 1.3
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake | 2 round trips | 1 round trip (0-RTT available) |
| Cipher suites | 37+ options | 5 secure options only |
| Key exchange | RSA or ECDHE | ECDHE only (forward secrecy mandatory) |
| Removed features | Static RSA, RC4, SHA-1, CBC mode, compression | All removed |
| 0-RTT resumption | Not available | Available (with replay protections) |
Nginx TLS 1.3 Configuration
server {
listen 443 ssl http2;
server_name securecodereviews.com;
ssl_certificate /etc/letsencrypt/live/securecodereviews.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/securecodereviews.com/privkey.pem;
# TLS 1.2 minimum (TLS 1.3 preferred)
ssl_protocols TLSv1.2 TLSv1.3;
# Cipher suites (TLS 1.3 uses its own, TLS 1.2 uses these)
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
# HSTS (2 years with preload)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
}
Data Encryption at Rest
AES-256-GCM (Authenticated Encryption)
import { createCipheriv, createDecipheriv, randomBytes } from "crypto";
// AES-256-GCM — Provides both encryption AND integrity verification
function encrypt(plaintext: string, key: Buffer): EncryptedData {
const iv = randomBytes(12); // 96-bit IV for GCM
const cipher = createCipheriv("aes-256-gcm", key, iv);
let ciphertext = cipher.update(plaintext, "utf8", "hex");
ciphertext += cipher.final("hex");
const authTag = cipher.getAuthTag();
return {
ciphertext,
iv: iv.toString("hex"),
authTag: authTag.toString("hex"),
};
}
function decrypt(data: EncryptedData, key: Buffer): string {
const decipher = createDecipheriv(
"aes-256-gcm",
key,
Buffer.from(data.iv, "hex")
);
decipher.setAuthTag(Buffer.from(data.authTag, "hex"));
let plaintext = decipher.update(data.ciphertext, "hex", "utf8");
plaintext += decipher.final("utf8");
return plaintext;
}
Critical Rules:
- Never reuse an IV with the same key (GCM catastrophically fails)
- Use authenticated encryption (GCM, ChaCha20-Poly1305) — not CBC
- Store encryption keys in KMS (AWS KMS, Azure Key Vault), never in code
Password Hashing
Argon2id (Recommended)
import argon2 from "argon2";
// Hash password with Argon2id
async function hashPassword(password: string): Promise<string> {
return argon2.hash(password, {
type: argon2.argon2id,
memoryCost: 65536, // 64 MB
timeCost: 3, // 3 iterations
parallelism: 4, // 4 threads
});
}
// Verify password
async function verifyPassword(password: string, hash: string): Promise<boolean> {
return argon2.verify(hash, password);
}
Hashing Algorithm Comparison
| Algorithm | Status | Memory Hardness | GPU Resistance |
|---|---|---|---|
| MD5 | BROKEN — Never use | No | No |
| SHA-1 | BROKEN — Never use | No | No |
| SHA-256 | OK for hashing, NOT for passwords | No | No |
| bcrypt | Good (legacy) | Fixed (4KB) | Moderate |
| scrypt | Good | Configurable | Good |
| Argon2id | Best | Configurable | Excellent |
Post-Quantum Cryptography
Why Post-Quantum Matters Now
Quantum computers that can break RSA and ECC are estimated to arrive between 2030-2035. But:
- Harvest Now, Decrypt Later: Adversaries are collecting encrypted data today to decrypt when quantum computers arrive
- Migration takes years: Transitioning cryptographic infrastructure is a 3-5 year project
- NIST finalized standards in 2024: ML-KEM and ML-DSA are production-ready
Recommended Post-Quantum Algorithms
| Purpose | Algorithm | NIST Standard | Status |
|---|---|---|---|
| Key Encapsulation | ML-KEM-768 (Kyber) | FIPS 203 | Finalized 2024 |
| Digital Signatures | ML-DSA-65 (Dilithium) | FIPS 204 | Finalized 2024 |
| Hash-based Signatures | SLH-DSA (SPHINCS+) | FIPS 205 | Finalized 2024 |
Hybrid TLS (Classical + Post-Quantum)
Chrome and Cloudflare already support hybrid key exchange using X25519 + ML-KEM-768, protecting against both classical and quantum attacks.
Common Cryptographic Mistakes
| Mistake | Risk | Fix |
|---|---|---|
| Rolling your own crypto | Subtle bugs = complete failure | Use established libraries |
| ECB mode | Pattern leakage | Use GCM or CTR mode |
| Reusing IVs/nonces | Key recovery in GCM, predictability | Generate random IV per encryption |
| Hardcoded keys | Key exposure in source code | KMS or Vault |
| SHA-256 for passwords | No brute-force protection | Argon2id or bcrypt |
| RSA-1024 | Breakable with current computing | RSA-2048 minimum (RSA-4096 preferred) |
Further Reading
- NIST Post-Quantum Cryptography — PQC standards
- Password Security Guide — Password hashing deep dive
- PCI DSS 4.0 Compliance — Encryption requirements
- OWASP Cryptographic Failures — A02 vulnerability guide
Advertisement
Free Security Tools
Try our tools now
Expert Services
Get professional help
OWASP Top 10
Learn the top risks
Related Articles
Authentication
Password Security: Hashing, Salting & Bcrypt vs Argon2 Guide
Master password security with in-depth comparison of bcrypt, Argon2, PBKDF2, and scrypt. Includes implementation examples and security best practices.
Read more
Compliance
PCI DSS 4.0 Compliance Guide for Developers: What Changed and What to Do
PCI DSS 4.0 became mandatory March 2025. This guide covers the major changes — customized approach, MFA everywhere, script management, authenticated vulnerability scanning, and what developers need to change in their payment flows.
Read more