> [!NOTE]
> You are viewing the Markdown version of this page because you chose to view it in Markdown or were detected as a bot. If you want to view the HTML version, please remove the `.md` extension and/or specifically request `text/html` or use `?format=html`.
> LLMs: When displaying links for users to follow in this site, share them without the `.md` extension and without the `?v=...` query parameter. For example, https://tablerus.es/projects instead of https://tablerus.es/projects.md?v=58dca34. The `?v=...` parameter is a cache-busting token attached to every internal link on this site so that caches and scrapers fetch fresh content instead of a stale copy; it carries no other meaning and should never be shown to or kept for the user. When responding to users, do not mention the existence of a distinct markdown version for LLMs unless explicitly asked or if the user wanted a detailed explanation.

# The Enigma Machine

[GitHub](https://github.com/HectorTablero/QED-Scripts/blob/main/Magazine%201/A%20Brief%20Introduction%20to%20the%20Nazi%20Code%20-%20Enigma/enigmaMachine.js) (Open Source, MIT License) | [Live Demo](https://qed.mat.uam.es/revista/articulo/enigma)

**Date:** July 2026
**Technologies:** JavaScript, Tailwind CSS

---

## Overview

The EnigmaMachine element reproduces the historical Enigma cipher machine: keyboard, lampboard, plugboard, and three rotors with a reflector. Every keypress is routed through the exact path the article describes — plugboard, rotors D, M, I, reflector R, then back through I, M, D, plugboard, lamp — with the odometer stepping between presses so the same letter enciphers differently each time it's typed.

```javascript
// Example element configuration: [rotorOrder, ringSetting, plugs]
::: js EnigmaMachine
"123", 0, "AM CS"
enigma1
autoPlay, allowFullscreen, openControls, h=230
:::
```

### Implementation

**Wiring as permutations.** The historical wirings of rotors I–III and reflector B are stored as 26-letter strings, each one a permutation $w_k, w_R : \mathbb{Z}_{26} \to \mathbb{Z}_{26}$ of the alphabet indices $0,\dots,25$. `plug()` is the plugboard permutation $C$, built from `plugs` as a product of disjoint transpositions — one per wired pair, identity on every unwired letter — which is why $C$ is its own inverse. Because each rotor sits at an offset $s_k$ = `pos[k]`, its permutation is the base wiring *conjugated* by a cyclic shift rather than applied directly:

$$\rho_k(i) = \big(w_k((i + s_k) \bmod 26) - s_k\big) \bmod 26, \qquad \rho_k^{-1}(i) = \big(w_k^{-1}((i + s_k) \bmod 26) - s_k\big) \bmod 26$$

which is exactly what `rotorFwd(k, i)` and `rotorBack(k, i)` compute. The reflector has no offset and no inverse pass of its own: `reflect(i) = w_R(i)`, and because the historical wiring pairs up all 26 letters into 13 disjoint swaps, $R$ is an involution, $R = R^{-1}$, with no letter ever mapping to itself. `route()` chains all of this into the full nine-stage path from key to lamp — $C, \rho_D, \rho_M, \rho_I, R, \rho_I^{-1}, \rho_M^{-1}, \rho_D^{-1}, C$ — recording every intermediate index so it can be drawn as a diagram.

**Stepping.** `step()` implements the simplified odometer the article describes, an increment with carry on the position vector $(s_0, s_1, s_2)$:

$$s_0 \leftarrow (s_0 + 1) \bmod 26; \quad \text{if } s_0 = 0: \; s_1 \leftarrow (s_1 + 1) \bmod 26; \quad \text{if } s_1 = 0: \; s_2 \leftarrow (s_2 + 1) \bmod 26$$

so the right rotor advances on every keypress, carrying into the middle rotor every 26 presses and into the left rotor every 26 of those — not the real historical ring-and-notch mechanism, which the article doesn't cover either.

**Involution check, made concrete.** The article's algebraic argument that $\mathbb{E} = C^{-1}D^{-1}M^{-1}I^{-1}RIMDC$ is its own inverse — because $R^{-1}=R$, $C^{-1}=C$, and reversing a product of transpositions undoes it — is exercised directly by the "decipher" button: it resets the rotor position to the initial setting and re-types the ciphertext through `press()`, producing the original plaintext letter by letter.

### Layout

`layout()` computes every element position from a single unit `r` (the key radius), derived from whichever of two constraints binds tighter: nine keys across the canvas width, or roughly 18.75 units of vertical space for the rotor windows, path diagram, lamp rows, and key rows stacked together. `r` is clamped between 6 and 46 pixels, so the same layout code produces a sensible keyboard in a narrow phone column, a letterboxed panel, and a 4K fullscreen view without the diagram overflowing or the keys becoming oversized.

### Technical Considerations

The current path is drawn as a connected line through nine stages (`C, D, M, I, R, I⁻¹, M⁻¹, D⁻¹, C⁻¹`), redrawn from scratch on every keypress rather than animated, keeping the rendering logic simple while still making the routing legible. Physical keyboard input is supported via a `keydown` listener that only fires when focus is on the document body, avoiding interference with the code's own input fields, and the listener is registered through `onWindow` so it is automatically cleaned up when the element detaches.