In modern software architecture and systems engineering, cryptography provides the bedrock for digital trust, communication confidentiality, and identity verification. Cryptographic systems are designed around four foundational security goals: Confidentiality (preventing eavesdropping), Integrity (detecting tampering), Authentication (confirming identity), and Non-repudiation (preventing denial).
This master cheat sheet catalogs modern cryptographic primitives across Symmetric Ciphers, Asymmetric Public-Key Systems, Cryptographic Hashes & Password KDFs, Digital Signatures, Key Exchange Protocols, and Production Engineering Pitfalls.
🔗 Related Cheat Sheets: Fundamental Network Communication Protocols Cheat Sheet · Network Security Protocols & Defensive Architecture Cheat Sheet · Core AI Algorithms Cheat Sheet
1. Five Core Cryptographic Paradigms Overview
| Paradigm | Mathematical Basis | Key Characteristics | Compute Performance | Reversible? | Typical Algorithms | Primary Production Workloads |
|---|---|---|---|---|---|---|
| Symmetric Encryption | Reversible substitution-permutation networks | Single shared secret key (must be securely distributed) | Extremely Fast (Native CPU AES-NI instructions) | Yes | AES-GCM, ChaCha20-Poly1305, SM4 | Bulk data transmission, database column encryption, full disk encryption |
| Asymmetric Encryption | Mathematical one-way trapdoor functions (Factoring, Elliptic Curve Discrete Log) | Public Key (distributed openly) + Private Key (kept strictly secret) | Slow (Compute-heavy modular exponentiation) | Yes | RSA-4096, ECC (P-256), Ed25519, SM2 | Key transport envelopes, digital certificates, hybrid session bootstrapping |
| Cryptographic Hashing | Compression functions mapping arbitrary inputs to fixed digests with avalanche effect | Keyless (can be salted) | Extremely Fast | No | SHA-256, SHA-3, BLAKE3, SM3 | File integrity verification, git commit hashes, blockchain state proofs |
| Message Authentication (MAC / AEAD) | Injects cryptographic authentication tags alongside ciphertext | Shared symmetric key + Unique Nonce | Extremely Fast | Ciphertext reversible | AES-GCM, ChaCha20-Poly1305, HMAC-SHA256 | TLS 1.3 packet transport, tamper-proof API payload signatures |
| Digital Signatures & Key Exchange | Sign with private key, verify with public key; or derive shared secret over untrusted channels | Signer holds private key; Ephemeral key pairs during exchange | Moderate | Signatures not reversible | Signatures: Ed25519, ECDSA, RSA-PSS Exchange: ECDHE, X25519 |
Code signing, Git commit verification, TLS Perfect Forward Secrecy |
2. Symmetric Ciphers & Block Modes
2.1 Symmetric Encryption Algorithms Compared
| Algorithm | Cipher Type | Standard Key Lengths | Security Level | Hardware Acceleration | Production Recommendation |
|---|---|---|---|---|---|
| AES (Advanced Encryption Standard) | Block Cipher (128-bit block) | 128 / 192 / 256 bits | ★★★★★ (Gold Standard) | Universal native CPU support (AES-NI) | The default choice for nearly all enterprise systems; prefer AES-256-GCM |
| ChaCha20 | Stream Cipher (256-bit key) | 256 bits | ★★★★★ (Top Tier) | High speed in software on mobile/ARM chips without hardware AES | Pair with Poly1305 (AEAD); standard in WireGuard, mobile TLS, and IoT |
| SM4 | Block Cipher (128-bit block) | 128 bits | ★★★★★ (Compliance) | Integrated in modern domestic/x86 silicon | Required for Chinese commercial compliance, financial fintech, and state standards |
| 3DES (Triple DES) | Block Cipher (64-bit block) | 112 / 168 bits | ★★☆☆☆ (Deprecated) | Slow | Broken by the Sweet32 collision attack; removed from NIST standards; legacy only |
| DES | Block Cipher (64-bit block) | 56 bits | ❌ Broken | - | 56-bit keys can be brute-forced in hours; strictly forbidden in modern software |
2.2 Block Cipher Modes of Operation
| Mode | AEAD Authenticated? | Parallelizable? | IV / Nonce Requirements | Vulnerability Profile | Production Recommendation |
|---|---|---|---|---|---|
| ECB (Electronic Codebook) | No | Yes | None (Deterministic) | Catastrophic: Identical plaintext blocks produce identical ciphertext blocks | ❌ Strictly forbidden everywhere |
| CBC (Cipher Block Chaining) | No | Decryption only | Random, unpredictable IV per message | Vulnerable to Padding Oracle attacks without strict Encrypt-then-MAC | Deprecated in TLS 1.3; avoid for new APIs |
| CTR (Counter Mode) | No | Yes (Enc & Dec) | Unique Nonce + Counter per message | Reusing a Nonce with the same key destroys confidentiality | Excellent primitive when combined with an authentication tag |
| GCM (Galois/Counter Mode) | Yes (AEAD) | Yes (High Throughput) | Strictly unique 96-bit Nonce per message | Reusing a Nonce compromises the authentication key | Industry standard default for web, databases, and microservices |
| XTS | No (Tweakable) | Yes | Sector / Block LBA address as Tweak | Designed specifically to avoid ciphertext expansion on random-access disks | Standard for full-disk and filesystem block encryption (BitLocker, LUKS) |
3. Asymmetric Encryption, Signatures & Key Exchange
| Primitive | Underlying Hard Problem | Recommended Key Size | Performance Profile | Quantum Resilience | Production Guidance |
|---|---|---|---|---|---|
| RSA | Large Integer Prime Factorization | $\ge 2048$ bits (3072/4096 recommended) | Fast public-key verification; slow private-key operations | Vulnerable (Shor's Algorithm) | Legacy compatibility; for signatures, mandate RSA-PSS padding over PKCS#1 v1.5 |
| ECDSA | Elliptic Curve Discrete Log (ECDLP) | 256 / 384 bits (secp256r1 / P-256) | Compact keys and fast signing | Vulnerable | Requires high-quality CSPRNG entropy; deterministic RFC 6979 prevents key leaks |
| Ed25519 (EdDSA) | Edwards Curve Discrete Log (Curve25519) | 256 bits (32-byte keys) | Extremely fast signing and verification; constant-time operations | Vulnerable | Gold standard for modern digital signatures (SSH, Git, modern tokens) |
| ECDHE / X25519 | Diffie-Hellman on Elliptic Curves | 256 bits | Fast key agreement generating ephemeral shared secrets | Vulnerable | Universal key exchange standard in TLS 1.3 and WireGuard (Perfect Forward Secrecy) |
4. Cryptographic Hashing vs. Password KDFs
4.1 Cryptographic Hash Functions (Data Integrity)
| Hash Function | Digest Size | Collision Resistance | Speed | Security Status | Primary Use Case |
|---|---|---|---|---|---|
| SHA-256 / SHA-512 | 256 / 512 bits | High | Fast | Standard | Digital signatures, TLS certificates, blockchain verification |
| SHA-3 (Keccak) | Variable (224-512) | High (Sponge construction) | Moderate | Standard | Immune to length-extension attacks; alternative to SHA-2 |
| BLAKE3 | 256 bits | High (Merkle tree tree-hashing) | Blazing (Multi-GB/s) | Modern High-Perf | High-throughput file deduplication, build systems, distributed caching |
| MD5 / SHA-1 | 128 / 160 bits | Broken (Collisions generated in seconds) | Fast | ❌ Insecure | Strictly forbidden in all security-sensitive environments |
4.2 Password Key Derivation Functions (Slow Hashes)
[!WARNING] Standard cryptographic hashes (SHA-256) are designed to be fast, making them trivial to brute-force on modern GPUs. Password storage mandates computationally and memory-hard Key Derivation Functions (KDFs).
| Algorithm | Memory-Hardness | GPU / ASIC Resistance | Tunable Parameters | Industry Verdict |
|---|---|---|---|---|
| Argon2id | Yes (Highly Tunable) | Highest (Resistant to side-channels and GPU clusters) | Memory cost ($m$), Time iterations ($t$), Parallelism ($p$) | Winner of the Password Hashing Competition; modern gold standard |
| bcrypt | Moderate (Blowfish state) | Moderate | Work factor / Cost ($2^{\text{cost}}$, recommended $\ge 12$) | Battle-tested, widely supported legacy standard |
| scrypt | Yes | High | CPU/Memory cost ($N$), block size ($r$), parallelization ($p$) | Strong memory hardness; popular in cryptocurrency wallets |
| PBKDF2 | No (Compute-only) | Low (Vulnerable to ASIC acceleration) | Iteration count (NIST recommends $\ge 600,000$ for PBKDF2-HMAC-SHA256) | Acceptable for legacy compliance; migrate to Argon2id when possible |
5. Global NIST/IETF Standards vs. Chinese Commercial Cryptography (SM)
| Cryptographic Function | International Standard (NIST / IETF) | Chinese National Standard (GM/T SM Series) | Security & Performance Equivalence | Typical Use Cases |
|---|---|---|---|---|
| Asymmetric / Signature | RSA-2048 / RSA-4096, ECDSA, Ed25519 | SM2 (256-bit Elliptic Curve) | 256-bit SM2 exceeds RSA-2048 security; comparable to ECC P-256 | Identity authentication, SSL dual-certificate systems |
| Cryptographic Hash | SHA-256, SHA-512 | SM3 (256-bit output digest) | Similar compression structure to SHA-256 with enhanced non-linear step design | Data integrity verification, digital notarization |
| Symmetric Block Cipher | AES-128, AES-256 | SM4 (128-bit block and key) | Security equivalent to AES-128; supports GCM for AEAD authenticated encryption | Database column encryption, financial transaction clearing |
| Stream Cipher | ChaCha20 | ZUC (Zuchongzhi) | High-performance stream cipher adopted in 3GPP 4G/5G mobile standards | Cellular telecommunications, real-time streaming obfuscation |
6. Eight Golden Engineering Rules for Cryptographic Safety
Rule 1: Never Use ECB Mode
AES-ECB encrypts identical plaintext blocks into identical ciphertexts,
revealing data outlines. Always use authenticated AEAD modes (AES-256-GCM).
Rule 2: Never Reuse a Nonce / IV
In GCM and ChaCha20, reusing a Nonce under the same secret key allows an attacker
to mathematically recover plaintexts and forge authentication tags.
Rule 3: Never Store User Passwords with Fast Hashes
Never use MD5, SHA-1, or plain SHA-256 for passwords. Mandate Argon2id or bcrypt (cost >= 12).
Rule 4: Purge Broken Algorithms
Eliminate DES, 3DES, RC4, MD5, and SHA-1 from all production configurations.
Rule 5: Use Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)
Generate keys, nonces, and salts using OS-level CSPRNGs (/dev/urandom, crypto.randomBytes).
Never use Math.random().
Rule 6: Prevent Timing Side-Channel Attacks
Compare hashes, signatures, and authentication tokens using constant-time comparisons
(e.g., crypto.timingSafeEqual) rather than standard string equality.
Rule 7: Mandate Perfect Forward Secrecy (PFS)
Use ephemeral key exchanges (ECDHE, X25519) in TLS handshakes so that future server
private key compromises cannot decrypt past recorded network sessions.
Rule 8: Decouple Keys from Application Source Code
Never commit secret keys into Git repositories. Inject keys dynamically via environment
variables or hardware-backed Key Management Systems (KMS / Vault) with automated rotation.