🧭 Start Here — The Vocabulary in One Panel
Every exhibit below uses a handful of load-bearing words. Here is each in one plain sentence, so the comparison table's Structure and transparency rows read like English, not jargon. Terms in the exhibits link back here.
- Block cipher
- A recipe that scrambles one fixed-size chunk of data (here, a block of 128 bits = 16 bytes) at a time. The same key both scrambles and unscrambles.
- Key
- The secret number that controls the scrambling. A 256-bit key is one of 2²⁵⁶ possibilities — far too many to guess. Bigger keys leave more headroom against future attacks.
- Round
- One pass of scrambling. Ciphers repeat a simple round many times (SM4 does 32); each round mixes the data a little more, so more rounds = larger security margin.
- S-box (substitution box)
- A fixed lookup table that swaps each byte for another (00→63, 01→7c, …). It is the non-linear heart of the cipher — the part that resists algebra. Whether its design is public and explained is the whole "transparency" question.
- SPN (substitution-permutation network)
- A round design that substitutes every byte (S-box), then permutes/mixes them across the whole block, then adds the round key. AES, ARIA, and Kuznyechik are SPNs. Every bit touches every other bit quickly.
- Feistel network
- A different round design: split the block in half, run one half through a scrambling function, XOR it into the other half, swap. Its trick is that encryption and decryption run the same circuit. Camellia and SM4 use Feistel structures.
- Involution
- A function that is its own inverse: apply it twice and you are back where you started, f(f(x)) = x. Reusing one involutory circuit for both encrypt and decrypt saves hardware. Watch for it in ARIA's diffusion layer (Exhibit 2).
- Diffusion layer
- The mixing step that spreads each byte's influence across the whole block, so one changed input bit avalanches into many changed output bits (Exhibit 5).
✅ Verified Against Official Test Vectors
Every cipher here runs real operations — no simulation. To prove it, the page
encrypts each cipher's known-answer test (KAT) from its defining
standard, right now in your browser, and checks the output byte-for-byte against the
published ciphertext. The same vectors gate the repository's npm test suite.
| Result | Vector | Source | Expected ciphertext |
|---|
🇯🇵 Exhibit 1 — Camellia-256
ISO/IEC 18033-3 · IETF RFC 3713 · CRYPTREC approved
Structure: Feistel network with SPN-like keying layers (FL/FL⁻¹)
Block size: 128-bit · Key sizes: 128, 192, 256-bit
Interactive Encrypt / Decrypt
Side-by-Side: Camellia-256-CBC vs AES-256-CBC
Same plaintext, same key, same IV — different ciphertext. Both decrypt correctly.
Camellia-256-CBC
AES-256-CBC
Same inputs, different ciphertext — because Camellia and AES are different algorithms. Two consequences follow, and both matter: first, interoperability requires both sides to agree on the algorithm — a Camellia sender and an AES receiver cannot talk, even with the identical key. Second, and just as important, "different-looking output" is not evidence of more security. Both here are 256-bit ciphers with comparable security margins; the divergent hex tells you they are distinct, not that either is stronger.
Round Structure
Camellia uses 18 rounds for 128-bit keys or 24 rounds for 192/256-bit keys. AES uses 10/12/14 rounds for the same key sizes. Camellia's extra rounds were a deliberate conservative design decision — more rounds mean a larger security margin against future cryptanalysis.
Camellia is on the IETF Standards Track for TLS (RFC 5932, originally RFC 4132), one of only two ciphers here that are — ARIA is the other (RFC 6209). But Camellia stands out for breadth of independent vetting: equivalent security to AES, a fully published design rationale, and active maintenance by Japan's CRYPTREC. For systems that need an AES alternative with the strongest international scrutiny, Camellia is the most defensible choice in this group.
🇰🇷 Exhibit 2 — ARIA-256
Korean Standard KS X 1213 · ISO/IEC 18033-3 · IETF RFC 5794
Structure: SPN (like AES) with an involutory diffusion layer
Block size: 128-bit · Key sizes: 128, 192, 256-bit
Interactive Encrypt / Decrypt
Where ARIA's Involution Really Lives
First, plainly: an involution is a function that is its own inverse — apply it twice and you are back where you started, f(f(x)) = x. ARIA is an involutional cipher, but the involution is in its diffusion layer, not its S-boxes. This distinction is commonly garbled; getting it right is the difference between understanding ARIA and parroting it.
1. The S-box is not involutory
ARIA's S₁ is the AES (Rijndael) S-box. Applying it twice does not return the original byte, so decryption needs a separate inverse, S₁⁻¹. Try any byte:
Note S₁(S₁(x)) ≠ x, but S₁⁻¹(S₁(x)) = x. That second, distinct table is exactly what an involution would let you avoid — and ARIA's S-boxes do not.
Watch the lookup happen in the table
The S-box is just a 16×16 grid of 256 output bytes. To look up S₁(x), split the input byte into its high nibble (the row) and low nibble (the column) and read the cell where they meet. Press Animate lookup to trace S₁, then S₁ again (landing somewhere else — the proof it is not an involution), then S₁⁻¹ back to your byte.
2. The diffusion layer is involutory
ARIA's 16×16 binary diffusion matrix A satisfies A(A(x)) = x for every 128-bit state (RFC 5794: "Note that A is an involution"). Apply it twice and you land back on your input — so the same diffusion circuit serves both encryption and decryption. That is ARIA's real hardware advantage.
ARIA is legally required for products sold into Korean government and financial markets. Its involutional diffusion layer is a deliberate engineering choice: reusing one diffusion circuit for both directions cuts hardware gate count. If you are building systems for Korean regulatory compliance, ARIA is not optional — and now you can say precisely why it is built the way it is.
🇨🇳 Exhibit 3 — SM4
GB/T 32907-2016 · ISO/IEC 18033-3
Structure: 32-round non-balanced Feistel network with a nonlinear T-transform (its S-box plus mixing)
Block size: 128-bit · Key size: 128-bit only (no 192 or 256-bit variant)
Interactive Encrypt / Decrypt
Watch the 32 Rounds Run
Encrypting above kicks off this schematic. SM4 keeps the 128-bit block as four 32-bit words (X₀ X₁ X₂ X₃). Each round takes the newest three words plus a round key, pushes them through the substitute → mix → add-round-key pipeline (that is the T-transform), and the result becomes the next word — a Feistel shift. Watch each stage light up: this is why 32 rounds diffuses a single input bit across the whole block, not just a dot to count.
Schematic of the real data flow (word rotation + T-transform per SM4 / GB/T 32907-2016). The hex words shown are the live state you just encrypted; the stage highlighting is illustrative timing, not a claim about gate-level latency.
SM4 has a fixed 128-bit key with no larger variant. Grover's algorithm gives a quadratic speedup against symmetric key search, so the headline figure is ~64-bit post-quantum security — versus the 128-bit PQ margin you get from a 256-bit key (Camellia-256, ARIA-256, Kuznyechik).
The honest nuance: Grover's search is inherently serial and parallelizes poorly (splitting it across machines only buys a √-factor), so under NIST's MAXDEPTH model the practical attack cost is far above 2⁶⁴. NIST still uses AES-128 as its post-quantum "Level 1" baseline. The real PQ threat is to asymmetric crypto, not to 128-bit symmetric ciphers per se.
Bottom line: SM4's fixed 128-bit key gives you no headroom to grow. For long-term, defense-in-depth data protection, prefer a 256-bit-key cipher where the choice is yours.
SM4 is required for products operating in Chinese markets, including WAPI (Chinese Wi-Fi standard, required for devices sold in China), Chinese banking systems, and government procurement. China's Cryptography Law (2020) mandates OSCCA-approved algorithms for certain categories of data.
The design rationale for SM4's S-box has been partially published but not with the same transparency as AES's design criteria.
If your product is sold or operated in China, SM4 is not a choice — it is a legal requirement. Understanding its structure and limitations (fixed 128-bit key, partial design transparency) is essential for any engineer working in Chinese-regulated markets.
🇷🇺 Exhibit 4 — Kuznyechik
GOST R 34.12-2015 · ISO/IEC 18033-3
Replaces the older GOST 28147-89 block cipher
Structure: SPN — a 10-round substitution-permutation network
Block size: 128-bit · Key size: 256-bit only
Interactive Encrypt / Decrypt
Kuznyechik's S-box was published without any design rationale. In 2019, independent researchers (Léo Perrin et al.) discovered that the S-box has an unusual hidden structure — it can be decomposed in ways that suggest it was not generated randomly, but was constructed using an undisclosed process. The FSB has not responded to these findings.
This is categorically different from:
- AES: S-box derived from multiplicative inverse in GF(2⁸), fully documented
- Camellia: design criteria published, S-box generation explained
- ARIA: involutory S-boxes, construction documented
Use Kuznyechik ONLY when Russian regulatory compliance requires it. The S-box transparency concern is unresolved. For any other use case, AES-256-GCM, Camellia-256, or ARIA-256 are preferable.
Kuznyechik is required by Russian law for government and certain commercial applications. The S-box controversy does not mean it is definitely backdoored — but the lack of design transparency is a meaningful distinction from every other cipher in this demo. Engineers should understand this tradeoff before deployment.
🌊 Exhibit 5 — The Avalanche Effect
A core requirement of any strong block cipher: flipping a single bit of input should change about half of the output bits, unpredictably. This is the avalanche effect (strict avalanche criterion). It's why ciphertext looks like noise and why you can't chip away at a block cipher one bit at a time. All four ciphers here exhibit it.
Flip One Bit, Watch Half the Ciphertext Change
Each cell is one of the 128 ciphertext bits. Highlighted cells flipped versus the original. A good cipher lands near 64/128 (≈50%) no matter which input bit you change — try a few.
🧩 Exhibit 6 — Why Mode Matters: ECB vs CBC
A strong cipher is not enough — how you chain blocks together matters just as much. ECB (Electronic Codebook) encrypts every 16-byte block independently, so identical plaintext blocks produce identical ciphertext blocks. That leaks structure. CBC chains each block into the next with an IV, so repetition disappears. This is the famous "ECB penguin" problem, shown here on raw blocks.
Encrypt Three Identical Blocks
The plaintext below is the same 16-byte block repeated three times. Watch what each mode does.
ECB — blocks encrypted independently
CBC — blocks chained with an IV
The Actual "ECB Penguin": Encrypt a Picture
Hex rows prove the leak; a picture makes it unforgettable. Below is a small image encrypted with a real block cipher two ways. In ECB, identical plaintext blocks (flat regions of the image) become identical ciphertext blocks, so the ghost of the original shows through. In CBC, chaining destroys the pattern and the same image turns to noise. Same cipher, same key — only the mode differs.
Each canvas renders real pixel bytes: the middle one is those bytes encrypted block-by-block in ECB, the right one in CBC. Nothing is faked — the ECB ghost is the cipher genuinely leaking the image's repeated blocks.
ECB is offered in Exhibit 1 strictly to make this failure visible. Production systems use an authenticated mode such as AES-256-GCM (or Camellia/SM4 in GCM). It hides block structure and detects tampering — ECB and even raw CBC do neither.
📊 Exhibit 7 — Four-Way Comparison
Comparison Table
| Property | Camellia-256 | ARIA-256 | SM4 | Kuznyechik |
|---|---|---|---|---|
| Country | Japan | South Korea | China | Russia |
| Designer | NTT / Mitsubishi | NSRI Korea | OSCCA | FSB Russia |
| Year | 2000 | 2003 | 2006 | 2015 |
| Block size | 128-bit | 128-bit | 128-bit | 128-bit |
| Key sizes | 128 / 192 / 256 | 128 / 192 / 256 | 128 only | 256 only |
| Structure | Feistel + SPN | SPN | Feistel | SPN |
| ISO/IEC 18033-3 | ✓ | ✓ | ✓ | ✓ |
| TLS cipher suite (RFC) | ✓ 5932 | ✓ 6209 | ✓ 8998 (TLS 1.3) | ✓ 9189 (TLS 1.2) |
| IETF status | Standards Track | Standards Track | Informational | Not endorsed |
| Design transparency | ✓ Full | ✓ Full | Partial | ✗ S-box opaque |
| PQ security (128-bit key) | ✓ | ✓ | ✗ (64-bit PQ) | ✓ |
| Use when | AES alternative | Korean compliance | China compliance | Russian compliance |
| Trust level | High | High | Medium | Use with caution |
Decision Tree
All four of these ciphers appear in crypto-compare. This demo covers the practical encrypt/decrypt behavior. For deeper algorithm reference including security estimates, see: systemslibrarian.github.io/crypto-compare/