Interactive Recommendation Guide
Cipher Recommendation Assistant
Select a real-world use case scenario (Web APIs, Password Hashing, IoT/Embedded, Post-Quantum, File Storage) or answer a step-by-step decision tree to discover recommended algorithms, security trade-offs, and implementation code snippets.
Select a Common Use Case Scenario
Web & API Security
Encrypting REST APIs, web traffic, and HTTPS/TLS session communications.
Password Hashing & Key Derivation
Safely storing user passwords in databases using memory-hard KDF functions & HMAC.
IoT & Embedded Microcontrollers
Low-memory microcontrollers or mobile chips lacking AES hardware acceleration.
File & Database Storage
Encrypting databases, cloud backups, and disk partitions (BitLocker/FileVault).
Digital Signatures & Identity
Authenticating software releases, API JWT tokens, and TLS certificates.
Post-Quantum Preparedness
Future-proofing data against quantum computer decryption attacks (NIST PQC).
Recommended Algorithms (83)
AES
recommendedWhy Recommended:
AES (GCM/XTS) is the gold standard for symmetric encryption worldwide. It features dedicated CPU hardware acceleration (AES-NI) on modern x86 and ARM processors.
Trade-offs & Considerations:
Requires hardware acceleration for top performance; without AES-NI, software-only performance can be slower than ChaCha20.
ChaCha20-Poly1305
recommendedWhy Recommended:
ChaCha20-Poly1305 is a high-speed AEAD stream cipher designed to run extremely fast in software without requiring specialized hardware instructions.
Trade-offs & Considerations:
Requires strict 96-bit nonce uniqueness per key to prevent security compromises.
SHA-256
recommendedWhy Recommended:
Secure Hash Algorithm 2. Produces a unique 256-bit hash output representing the input message.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Bcrypt
recommendedWhy Recommended:
A password hashing function incorporating a salt and cost factor, designed to be slow to prevent brute force.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
One-Time Pad (OTP)
secureWhy Recommended:
An unbreakable cipher when used with a truly random, single-use key of equal length to the plaintext.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
AES-XTS
secureWhy Recommended:
A tweakable mode (IEEE P1619) for disk-sector encryption, composed from the existing AES module — the sector number IS the tweak, so no IV needs to be stored per sector. Confidentiality-only, no authentication tag (unlike AES-GCM).
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Camellia
secureWhy Recommended:
A symmetric key block cipher jointly developed by Mitsubishi Electric and NTT, widely used and standardized (RFC 3713).
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Serpent
secureWhy Recommended:
An AES finalist (1998, runner-up to Rijndael) with the largest security margin of the finalists — 32 rounds using 8 different S-boxes cycled per round, versus AES's single S-box.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Speck128/128
secureWhy Recommended:
An NSA lightweight ARX cipher (2013) using only addition, rotation, and XOR — no S-boxes or lookup tables at all, unlike every other symmetric cipher in this registry.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
AES-CCM
secureWhy Recommended:
Counter with CBC-MAC (NIST SP 800-38C) — an authenticated mode composed from AES, contrasted with AES-GCM: authentication here is literal CBC-MAC re-running the block cipher, not GHASH polynomial evaluation.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Threefish-256
secureWhy Recommended:
A tweakable, large-block ARX cipher (2008) underlying the Skein hash function (a SHA-3 finalist). 256-bit block, 72 rounds, and a 128-bit tweak that varies ciphertext without changing the key — no other cipher here exposes a tweak input.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
XChaCha20
secureWhy Recommended:
The 192-bit-nonce extension of ChaCha20 (used by libsodium) — an HChaCha20 subkey-derivation step, the ChaCha20 sibling of this batch's XSalsa20, lets you pick nonces randomly instead of managing a counter.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Twofish
secureWhy Recommended:
AES finalist by Bruce Schneier et al. (1998). 128-bit block, 128/192/256-bit keys, 16-round Feistel. Uses key-dependent S-boxes (derived via RS matrix over GF(2^8)), MDS matrix diffusion, PHT, and 40 subkeys. Used in GnuPG and VeraCrypt. Never broken.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
GOST 28147-89
secureWhy Recommended:
The Soviet/Russian government standard block cipher (declassified 1994) — 256-bit key, 32-round Feistel. Uniquely, the S-boxes are a negotiated parameter, not fixed by the standard; this demo uses a published reference set.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ASCON-128
secureWhy Recommended:
NIST-selected lightweight cryptography standard (SP 800-232, 2023). Authenticated encryption with associated data (AEAD) — encrypts and authenticates simultaneously using a 320-bit sponge permutation. Designed for IoT and constrained devices. Output = nonce + ciphertext + 128-bit tag.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
XSalsa20
secureWhy Recommended:
The 192-bit-nonce extension of Salsa20 (used by NaCl/libsodium) — an HSalsa20 subkey-derivation step lets you pick nonces randomly instead of managing a counter.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SM4
secureWhy Recommended:
Chinese national standard block cipher (GB/T 32907-2016, ISO/IEC 18033-3, RFC 8998). Mandatory in Chinese internet and financial infrastructure; now part of TLS 1.3 cipher suites. 128-bit block, 128-bit key, 32-round SPN with a single S-box and linear transform.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SIMON-32/64
secureWhy Recommended:
NSA lightweight block cipher targeting 8/16-bit microcontrollers. Uses 16-bit words, a 32-bit block, and a 64-bit key across 32 Feistel rounds. The smallest variant of the SIMON family.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
NOEKEON
secureWhy Recommended:
NESSIE-submitted 128-bit block cipher. Unique for having ZERO lookup tables; its non-linear Gamma layer uses exactly 5 bitwise AND/OR/XOR operations. Ideal for VLSI/FPGA environments.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
LEA
secureWhy Recommended:
Korean lightweight ARX block cipher (IETF RFC 9998, 2024). Pure Add/Rotate/XOR — no S-boxes, making it 3–4× faster than AES on 32-bit processors. 128-bit block, 128/192/256-bit keys, 24/28/32 rounds. Used in Korean IoT and mobile applications.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
GIFT-64
secureWhy Recommended:
Ultra-lightweight 64-bit block cipher (CHES 2017). Uses a 4-bit S-box and 28-round SPN. 5x more hardware-efficient than PRESENT and underlies the NIST Lightweight Finalist GIFT-COFB.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Streebog-256
secureWhy Recommended:
Russian national hash function (GOST R 34.11-2012, RFC 6986). 512-bit internal state processed through 12 rounds of a Kuznyechik-family SPN in a Miyaguchi-Preneel-like compression function, with a unique checksum-based finalization step.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Kuznyechik
secureWhy Recommended:
Russian national block cipher (GOST R 34.12-2015, RFC 7801). 128-bit block, 256-bit key, 9-round SPN. Replaces the legacy 1989 GOST cipher. Uses a fixed 256-byte S-box and a linear transform built from 16 GF(2^8) feedback steps.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SIMON-128/128
secureWhy Recommended:
NSA hardware-optimised lightweight block cipher (IACR 2013/404). Sibling of SPECK — SIMON targets gate-minimal hardware via bitwise AND while SPECK targets software via ARX. 128-bit block, 128-bit key, 68-round Feistel. Round function: f(x)=(x<<<1 & x<<<8)⊕x<<<2.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Rabbit
secureWhy Recommended:
eSTREAM Portfolio Phase 3 stream cipher (RFC 4503). 128-bit key, 64-bit IV. Distinctive non-linear counter system (no LFSR) using 64-bit squaring and XOR to generate 128 bits of keystream per iteration. Extremely fast in software.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
HC-128
secureWhy Recommended:
eSTREAM Phase 3 software-profile stream cipher by Hongjun Wu. Uses two 512-word (2 KB each) key/IV-derived lookup tables P and Q that update themselves during keystream generation. The fastest stream cipher in the eSTREAM portfolio on 32-bit software. Output = IV(32 hex) + ciphertext.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Anubis
secureWhy Recommended:
NESSIE-submitted block cipher (2000). 128-bit block, 128/192/256-bit key. Unique involutional design: the S-box, diffusion layer, and round structure are all self-inverse. Decryption is literally the same code as encryption, just with reversed round keys.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
MARS
secureWhy Recommended:
IBM AES finalist (1998). 128-bit block, 32-round heterogeneous SPN. Unique for combining 4 different round types (forward mixing, forward E-rounds, backward E-rounds, backward mixing) for defense-in-depth. Lost to Rijndael (AES) on performance/simplicity, but unbroken.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
CLEFIA
secureWhy Recommended:
ISO/IEC 29192-2 lightweight block cipher (Sony, 2007). 4-branch generalized Feistel network (GFN) with parallel F0/F1 functions using distinct S-boxes and diffusion matrices. Pairs with PRESENT to complete the ISO lightweight standard duo.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
MISTY1
secureWhy Recommended:
CRYPTREC-recommended, RFC 2994. 64-bit block, 128-bit key. Unique recursive Feistel network: main rounds call FO, which calls FI, which uses 7-bit/9-bit S-boxes. Ancestor of KASUMI (3G/GSM).
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ARIA
secureWhy Recommended:
Korean national standard block cipher (KS X 1213, RFC 5794). AES-like SPN but alternates between two involutional S-box pairs (SB1/SB2) and uses a pure GF(2) involutional diffusion matrix. Completes the SEED/LEA/ARIA Korean trio.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SHA-512
secureWhy Recommended:
Secure Hash Algorithm 2 with 64-bit words, producing a secure 512-bit digest.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SM3 Hash
secureWhy Recommended:
Chinese National Standard cryptographic hash function (GB/T 32905-2016). Produces a 256-bit message digest using 64 ARX compression rounds.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
HMAC-SHA256
secureWhy Recommended:
HMAC-SHA256 provides keyed message authentication and integrity verification, ensuring data cannot be altered by an unauthorized party.
Trade-offs & Considerations:
Requires both parties to hold the pre-shared secret key securely.
AES-CMAC
secureWhy Recommended:
A MAC built entirely from AES block-cipher calls plus a GF(2^128) subkey-derivation step (NIST SP 800-38B) — no separate hash function, unlike HMAC. Composed from the existing AES module, no new dependencies.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Bloom Filter Simulator
secureWhy Recommended:
A space-efficient probabilistic data structure testing set membership with zero false negatives and a tunable false-positive probability.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
HKDF (HMAC Key Derivation)
secureWhy Recommended:
HMAC-based Extract-and-Expand Key Derivation Function (RFC 5869) that converts weak or shared input keying material into cryptographically strong output keys.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
BLAKE2s
secureWhy Recommended:
The 32-bit-word sibling of BLAKE2b (2012), optimized for 8- to 32-bit platforms — smaller blocks, fewer rounds, 256-bit max output. Used internally by Argon2.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SHA-224
secureWhy Recommended:
A truncated SHA-2 family member (FIPS 180-4) with its OWN initial hash value — not simply SHA-256's output cut short, which is a deliberate design choice to prevent leaking one digest from the other.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SHA-384
secureWhy Recommended:
The 384-bit truncated member of the SHA-512 family (FIPS 180-4), with its own distinct initial hash value, same design principle as SHA-224 relative to SHA-256.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
PBKDF2
secureWhy Recommended:
RFC 8018 (PKCS #5). The most widely deployed KDF in the world (WPA2, iOS keychain). Iteratively applies HMAC to a password+salt. Slower iteration counts increase brute-force resistance.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Argon2id
secureWhy Recommended:
PHC Winner (2015), RFC 9106. Memory-hard password hashing with hybrid addressing (Argon2i for side-channel resistance, Argon2d for GPU resistance). Modern successor to bcrypt.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Skein-256
secureWhy Recommended:
SHA-3 finalist (Skein v1.3, 2010) by Schneier et al. Built on Threefish-256 via UBI (Unique Block Iteration) chaining — a Davies-Meyer construction. Pipeline: Config → Message → Output. Each block encrypted with Threefish-256 then XORed with plaintext. 256-bit output.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
LSH-256
secureWhy Recommended:
Korean national hash standard (KS X 3262, 2014). Wide-pipe ARX+Boolean design with 1024-bit internal state. Completes the SEED/LEA/ARIA/LSH Korean cryptographic suite.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Tiger
secureWhy Recommended:
Fast 192-bit hash designed for 64-bit processors (Anderson & Biham, 1995). Uses three 64-bit chaining variables and 3 passes of 8 rounds over four 256-entry 64-bit S-boxes. Fills the 192-bit output gap in this repo.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Grøstl-256
secureWhy Recommended:
SHA-3 finalist (2008). AES-based wide-pipe hash using dual permutations P and Q in a Davies-Meyer-like compression function. Operates on an 8x8 byte state with AES-style SubBytes/ShiftBytes/MixBytes rounds.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
RSA-2048
secureWhy Recommended:
Widely adopted public-key cryptosystem used for key transport and digital signatures.
Trade-offs & Considerations:
Requires large key sizes (minimum 2048/3072 bits) compared to ECC.
DSA
secureWhy Recommended:
The finite-field discrete-log ancestor of ECDSA (NIST FIPS 186, 1994) — same r/s signature equation, computed in a prime-order subgroup instead of on a curve. Demo uses toy parameters; real DSA needs p>=2048 bits, q>=224 bits.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Diffie-Hellman
secureWhy Recommended:
A key exchange protocol enabling two parties to establish a shared secret over an insecure channel.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
X448
secureWhy Recommended:
Diffie-Hellman key exchange over Curve448 (RFC 7748) — the higher-security sibling of X25519, targeting ~224-bit security with 56-byte keys instead of X25519's 32-byte keys.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ECC (ECDSA P-256)
secureWhy Recommended:
Elliptic Curve Cryptography. Implements ECDSA signing and verification over the NIST P-256 curve.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Schnorr (BIP340)
secureWhy Recommended:
Schnorr signatures per BIP340 over secp256k1, using x-only public keys. Provably secure under a simpler assumption than ECDSA and supports clean signature aggregation (MuSig) — compare against ecdsa.ts on the same curve.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ElGamal Signature
secureWhy Recommended:
The ElGamal signature scheme (1985) — distinct from ElGamal encryption already in this registry. Historically the direct ancestor of DSA: DSA is this scheme computed in a smaller prime-order subgroup for shorter signatures.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ML-DSA-65
secureWhy Recommended:
Post-quantum digital signatures (NIST FIPS 204, formerly Dilithium), pairing with ML-KEM the same way Ed25519 pairs with X25519 classically — except the hard problem here is lattice-based (Module-LWE/SIS), not elliptic-curve discrete log.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ECIES (X25519)
secureWhy Recommended:
Hybrid encryption: ephemeral X25519 key agreement + HKDF + AEAD, letting a sender encrypt an arbitrary-length message directly to a recipient's public key — no other asymmetric module here does this end-to-end.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ML-KEM-768
secureWhy Recommended:
Post-quantum key encapsulation (NIST FIPS 203, formerly Kyber), based on the Module Learning With Errors lattice problem — secure against both classical and quantum attackers, unlike every other asymmetric module here.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
FrodoKEM-640
secureWhy Recommended:
Post-quantum key encapsulation mechanism (KEM) based on unstructured Learning With Errors (LWE) on standard matrices, offering conservative security without algebraic ring assumptions.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Ed448
secureWhy Recommended:
EdDSA signatures over Curve448 (RFC 8032) — the higher-security-margin sibling of Ed25519, using SHAKE256 internally instead of SHA-512. Completes the Curve25519/Curve448 x agreement/signing grid alongside x25519, x448, and ed25519.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Shamir's Secret Sharing
secureWhy Recommended:
A threshold scheme (1979): splits a secret into N shares such that any K reconstruct it, but K-1 reveal nothing. Uses GF(256) polynomial arithmetic — a different mathematical toolkit from every other module here.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
NTRU
secureWhy Recommended:
Lattice-based public-key cryptosystem (IEEE P1363.1, 1996). Operates in polynomial ring Z[x]/(x^N-1). Predates NIST PQC by 20+ years. WARNING: Visualizer uses small pedagogical parameters (N=11) for teaching; NOT secure at this size.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SHAKE128
experimentalWhy Recommended:
An extendable-output function (XOF, NIST FIPS 202) — unlike every other hash here, output length is a parameter you choose, not fixed. Same Keccak permutation family as SHA-3.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SHAKE256
experimentalWhy Recommended:
The wider-capacity sibling of SHAKE128 (NIST FIPS 202) — same extendable-output design, larger security margin.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Trivium
legacyWhy Recommended:
eSTREAM Phase 3 stream cipher (ISO/IEC 29192-3). Three coupled 93/84/111-bit NLFSRs with 288-bit total state. 80-bit key, 80-bit IV, 1152 warm-up clocks before keystream. Most analysed stream cipher — one AND gate per output bit in hardware. Output = IV(20 hex) + ciphertext.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
PRESENT
legacyWhy Recommended:
Ultra-lightweight block cipher (ISO/IEC 29192-2:2012). Smallest standardised cipher: PRESENT-80 fits in 1,075 gate equivalents — vs AES's ~3,400 GE. 64-bit block, 80 or 128-bit key, 31-round SPN with a 4-bit S-box and a 64-bit bit-permutation P-layer.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
TEA
legacyWhy Recommended:
The original 1994 predecessor to XTEA (also in this registry). Simple ARX Feistel cipher, no S-boxes — but has a documented equivalent-key weakness (4 related keys produce identical ciphertext), which XTEA's extra key mixing was designed specifically to fix.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
XXTEA
legacyWhy Recommended:
Corrected Block TEA (Wheeler & Needham, 1998). The final and strongest member of the TEA family. Unlike TEA/XTEA, it operates on the entire message as a single variable-length block (min 2 words) for full diffusion. Widely used historically but unauthenticated.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Blowfish
legacyWhy Recommended:
Bruce Schneier's 1993 Feistel block cipher — pre-AES era workhorse used in SSH, OpenSSH, and the bcrypt key schedule. Unique for its key-dependent S-box structure: the 4×256 S-boxes are entirely re-derived from each key, making it immune to weak-key attacks that plagued DES.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
SEED-128
legacyWhy Recommended:
Korean national block cipher (RFC 4269, 2005; ISO/IEC 18033-3). Mandatory in Korean financial and government systems for over a decade. 128-bit block, 128-bit key, 16-round Feistel with G-function using two GF(2^8)-derived S-boxes. Superseded by LEA for new Korean deployments.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Caesar Cipher
brokenWhy Recommended:
A simple shift substitution cipher where each letter in the plaintext is shifted by a fixed number of positions.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
ROT13
brokenWhy Recommended:
A special case of Caesar cipher with a fixed shift value of 13.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Vigenère Cipher
brokenWhy Recommended:
A polyalphabetic substitution cipher that uses a keyword to shift characters in repeating cycles.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Atbash Cipher
brokenWhy Recommended:
A monoalphabetic substitution cipher formed by reversing the alphabet (A becomes Z, B becomes Y, etc.).
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Playfair Cipher
brokenWhy Recommended:
A polygraphic substitution cipher that encrypts pairs of letters using a dynamic 5x5 key matrix.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Rail Fence Cipher
brokenWhy Recommended:
A transposition cipher where plaintext is written diagonally down and up on successive "rails" of a fence.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
XOR Cipher
deprecatedWhy Recommended:
A simple stream cipher performing byte-wise XOR operations between plaintext and key.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
DES
brokenWhy Recommended:
Data Encryption Standard. A legacy 64-bit block cipher utilizing a 56-bit key size.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
3DES (Triple DES)
deprecatedWhy Recommended:
Applies the DES algorithm three times to each data block with two or three keys to increase security.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
RC2
brokenWhy Recommended:
Ron Rivest's 1987 variable-key block cipher (RFC 2268). First cipher exportable from the US under 1990s export controls via "effective key bits" parameter. Used in SSL 2/3, TLS, and S/MIME. Mix-and-mash round structure. Historical/educational only — broken at ≤40-bit effective keys.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
Enigma (I, 3-rotor)
brokenWhy Recommended:
The historical WWII 3-rotor Wehrmacht cipher machine, with plugboard and reflector. Self-reciprocal (same settings encrypt and decrypt), and — a real historical weakness — no letter ever maps to itself.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
KASUMI
brokenWhy Recommended:
3GPP TS 35.202 (GSM A5/3, UMTS f8/f9). MISTY1-derived hardware-optimized cipher. Status: BROKEN (2010 related-key attack). Included for educational value as a once-deployed mobile standard.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
MD5
brokenWhy Recommended:
A widely used legacy hash producing a 128-bit output. Cryptographically broken due to collision vulnerabilities.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
XXHash32
deprecatedWhy Recommended:
A very fast non-cryptographic 32-bit hash used for checksums, hash tables, and data integrity demos.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.
MD4
brokenWhy Recommended:
The direct predecessor to MD5 (1990) — fully broken today. Simpler than MD5: only 3 rounds (vs MD5's 4) and no additive per-step constants, illustrating exactly what MD5 was designed to fix.
Trade-offs & Considerations:
Standard cryptographic trade-offs apply.