Eye Cipher Field Notes

I unpacked the game files and checked where the eyes come from. They aren't in the game's scripts; they're built into the program itself as encoded numbers. A research helper decoded those numbers independently and they match the community's transcription exactly. I also re-derived the known statistics (83 symbols, no doubled symbols, the evenness of the distribution) and got the published values.

One of the simplest deck ciphers a programmer might write: each letter means "take the card at position k and move it to the top" (or to the bottom). For these designs you can work backwards from the symbols without knowing the key. If the eyes used one, the recovered positions would cluster into an alphabet-sized set of about 26–40 values. They don't. They spread over 59 different values, exactly like random noise.

Because 83 is a prime number, mathematicians can list every possible "shape" a cipher like this can have. There are only six. The community had already eliminated the two smallest. Two more, built on multiplication and addition on a clock face with 83 hours (their names are AGL(1,83) and C83:C41), were only marked "tentatively ruled out", with a note saying "TODO: why?".

These two families have a rigid property: once you know where two symbols go, you know where every symbol goes. So I turned the repeated patterns in messages 5, 7, 8 and 9 into a large system of equations and had a computer check every possibility exhaustively. There is no solution.

How strong

It still holds if I throw away any one or any two of the nine repeated patterns I used (46 variations), and if I trim five symbols off both ends of every pattern. For the smaller family, a single repeated phrase in messages 7, 8 and 9 is enough on its own.

Sanity check

I encrypted fake messages with a real cipher from this family and ran the same test. It correctly said "possible" and even recovered the hidden key. On ordinary deck ciphers it correctly said "impossible".

What's left

Only the two "full deck" families remain: all possible shuffles, and the even-numbered half of them. That confirms what the community suspected, now with a checkable proof.

The community's best guess is that every letter's shuffle is almost the same: one shared base shuffle plus a handful of card swaps. That's needed to explain spots where two messages disagree for a few symbols and then match again. The clearest example, the "funny-looking obstacle" in messages 1 and 2, goes 4 different, 4 same, 4 different, then 13 the same.

I simulated thousands of such ciphers on ordinary English text and measured two things.

• Does the obstacle show up naturally? Only when shuffles differ by about one swap. With four or more swaps it essentially never happens.
• Do the repeats look like the eyes? In the eyes, how often a symbol comes back after 2, 3, 4… positions is fairly even. When shuffles are nearly identical, most of the deck moves the same way every time. Cards then come back at a few favourite distances, giving a spiky pattern the eyes don't have. That spikiness only fades at around twelve or more swaps.

So either the obstacle has some other explanation, or the shuffles are related in a different way than "base plus a few swaps".

There's a variant that removes the conflict. Suppose letters are sorted into a few groups, and every letter in a group shuffles the deck the same way, differing only in which card it reads. Then swapping two words whose letters fall in the same groups leaves the deck exactly in sync. That explains the obstacle and the shared message openings. The shuffles themselves can still be thorough, which keeps the repeats even. The idea is called XGAK in the community's notes and was raised briefly on the Discord on 13 October. The community had set it aside as unnecessary.

A hint from the data: messages often keep matching symbol-for-symbol long after their texts have parted ways. That shouldn't happen if the decks had drifted apart. For example, messages W2, E3, E4, W4 and E5 all show the same symbol at position 20, even though W2 split from the others at position 6:

Pooled over all message pairs, symbols match at the same position 4–6 times more often than chance in the 25 positions after the texts diverge. Then the excess fades.

I simulated the shared-shuffle variant the same way as entry 4. Letters fall into a few groups and each group has one thorough shuffle. The only extra rule is that a card that has just been read is never in a reading spot on the next step, so the same symbol can't come out twice in a row. (My first version used a stricter rule, a fixed "reading area" that read cards are pushed out of. That made cards come back two steps later too often. This looser rule fixes that.)

Even repeats

92–100% of simulated ciphers look as even as the eyes once there are two or more letter groups. The "few swaps" models managed 2–8% at swap counts that also allow the obstacle.

Repeats 2 apart

The eyes have only 5. The model gives that few in 7–11% of simulated ciphers, so it's not a problem.

No doubles

Never, by construction, matching the eyes.

The obstacle

Two messages fall perfectly back into step whenever the swapped words use letters from the same groups. With letters split randomly into groups, about 10% of random word pairs do with 2 groups, about 3% with 3, and 1% or less with 4 or more. So the obstacle favours very few groups, or groups with a meaning (for example "all digits", which would make any two 4-digit numbers interchangeable). In the "few swaps" models, a 4-letter swap followed by 13 matching symbols essentially never happened. (Fixed a bug here: my first run sometimes "swapped" a word with itself, which inflated these rates.)

Late matches

When two messages' decks stay in step, a matching symbol simply means the same hidden letter. I tested the late matches against a fair "decks have drifted apart" baseline. Leaving out the two famous cases (the obstacle and the "stutter" in messages 7 and 9), there are 35 matches where about 12 are expected (p ≈ 0.01). With them included it's far beyond chance.

This doesn't prove the shared-shuffle variant is right, but on every test so far it beats the community's working assumption. If it holds, it's useful: a matching symbol in two in-step messages means "same hidden letter here", and the number of unknown shuffles drops from one per letter to one per group.

• No hidden rhythm. The repeat counts at distances 4, 9, 13 and 17 looked like they might recur every ~4.3 steps, which would hint at a conveyor-belt shuffle. A proper test says that's within chance (p ≈ 0.11).
• The famous excess at distance 4 is text, not mechanism. 15 of the 23 cases come from four words, each repeated three to five times, that happen to contain a distance-4 repeat. Counting each repeated word once leaves 12 cases where chance predicts about 14.
• Correction: the shortfall at distances 2 and 3 is not unusual. Symbols come back two or three positions later only about half as often as pure chance would give (13 cases where about 28 are expected). I first called that significant (p ≈ 0.001). But I had compared against random noise, and a deck cipher doesn't behave like noise here. Whether a card comes back after two steps depends only on the two letters in between. So the count hinges on a handful of letter pairs and swings a lot from key to key. Simulating real deck ciphers on real text, a shortfall this big turns up 12–26% of the time in English and 13–18% in Finnish. There is nothing special to explain.

Several results above rest on simulations, and the simulations need some stand-in for the hidden text. I'd only used English. The developers are Finnish (the enemies have Finnish names), and Finnish looks quite different on paper. It uses fewer letters (no B, C, F, Q, W, X or Z in ordinary words), has ä and ö, and has more than twice as many doubled letters as English ("kk", "aa", "ll"…).

The game ships no Finnish translation to borrow from, so I wrote about 25 KB of ordinary Finnish prose (folk-tale and everyday text) and reran every language-dependent test. I tried three versions: with ä and ö, with them folded to a and o (as a programmer might do), and with spaces removed.

Few-swaps conflict (entry 4)

Same picture. The chance of both the even repeats and the obstacle is at most 0.004% in Finnish (0.05% in English).

Shared shuffles (entry 6)

Same picture. Even repeats 95%, obstacle recreated about 10% of the time with 2 letter groups.

Distance-2/3 check (entry 7)

Same conclusion: not unusual (13–18%).

Caveat: 25 KB is a small sample of one writing style. It captures the letter mix and doubled letters, which is what drives these tests, but a real Finnish book would be a better check.

The extreme version of shared shuffles has a single group: every letter moves the deck the same way and only picks a different card. Then the deck depends only on how far into the message you are, never on the text. Two messages would hold the same deck at every position. Wherever their hidden letters happened to agree they would show the same symbol, about 7% of the time for English or Finnish.

In the eyes, once two messages have been apart for 30 or more positions, they match at the same spot 35 times out of 2,531 (1.4%). Pure chance gives 1.2%. So the deck's movement must depend on the text, and there must be at least two groups.

The community's notes say nobody has a method for recovering the shuffles of a deck cipher, even with the hidden text in hand. For the shared-shuffle variant I now have one, at least on fake messages.

The trick. Whether two symbols in a message match depends only on the hidden letters between them, not on the state of the deck before. So the messages break into thousands of small, overlapping logic puzzles: "these letters, applied in this order, must bring this card back to a reading spot". An off-the-shelf logic solver (a SAT solver) can chew through puzzles like that.

The test. I encrypted nine fake messages, the same lengths as the eyes and starting from the same deck, with two letter groups and random shuffles. Then I gave the solver the ciphertext plus the hidden text and asked it for the shuffles. I counted it a success only if the recovered shuffles reproduce every match and non-match between symbols in the full messages (about 60,000 pairs), including far beyond what the solver was shown.

Less text needed than you'd think

On the 23-card deck, knowing only the first 20 letters of each message was enough to recover shuffles that decrypt everything after them.

Wrong guesses fail fast

Given a wrong text, or the right text with just 2% of its letters changed, the solver reports "impossible" in under a second.

It only needs the pattern

The solver doesn't need actual letters, only which positions share a letter and which group each letter is in. So a guess like "these two words are the same" can be tested without knowing the language.

What it can't do yet. We know none of the eyes' hidden text, so there's nothing to feed it. I also tried giving it only the ciphertext. That works in principle on tiny decks, but at 83 cards repeats are so rare that the ciphertext alone doesn't contain enough clues for this kind of solver without some knowledge of the language. The realistic use is checking guesses: if the eyes are this kind of cipher and someone guesses enough of how the messages begin, the solver can confirm it and read the rest.

The big caveat. Speed grows quickly with deck size: about a minute at 41 cards and 3.5 minutes at 53 (after two speed-ups; 20 minutes without them). Whether 83 cards is practical is what the current runs will show.

Update (83 cards): the full-size run finished. Given the whole text and the letter groups, the solver recovered the exact key in 6.5 hours, reproducing all 60,000 checked pairs. So recovering the shuffles of an eye-sized deck from known text works; it is just slow.

Update: the solver no longer needs to be told which letters share a shuffle. With two groups it works that out too, and still recovers the exact key on the test decks.

A test that says "consistent" to everything is useless, so I measured where the solver starts rejecting wrong guesses. The wrong guesses were made to look like honest ones. Wherever two messages show identical symbols at the start, the guess uses identical text there, and it changes letters exactly where the messages split. The first symbol of each message gets a digit 1–9, and the rest is ordinary Finnish-like text. I ran these guesses against the real eyes, where every random guess is wrong. I also ran them against fake eye-like messages with a known key, where the true guess must pass.

Short guesses

For the eyes' 83-card deck, a guess covering up to about 21 symbols of every message can always be made to fit. I confirmed this directly: a new GPU search finds a fitting key for wrong 21-symbol guesses within seconds. So nobody can test a short guess this way, however good the solver gets.

Long guesses

From about 30 symbols per message, wrong guesses usually fail within a minute. That's 270 positions, but the shared openings repeat the same text, so only about 160 of them are separate letters to guess. And only the pattern matters (which positions hold the same letter), not which letters they are.

In between

From 22 to 29 symbols, neither the SAT solver nor the GPU search reaches an answer in reasonable time yet, even for the true guess.

Practical rule

To test a guess about the eyes, cover at least the first 30 symbols of every message. "Impossible" then means no. A long guess that survives is interesting, but not proof.

Speed work. I tried several speed-ups. Re-encoding how the messages share a starting deck made tests about 4× faster. Building guesses up one symbol at a time made wrong guesses fail about 40× faster on small decks. A stricter way to avoid relabeled duplicate answers turned out 2–3× slower, so I dropped it. A GPU search (CUDA, on both machines) finds fitting keys for guesses up to about 21 symbols in seconds, where the SAT solver needed minutes or gave up. Past that point it stalls too, so the middle zone is still open.

An obvious next question: forget guessing. Is there any two-group key and any hidden text that would produce the eyes? If not, the model is dead. If yes, the answer might show us the letter pattern.

I let the GPU search choose the letters too, and gave four ciphertexts identical effort. All four share the eyes' openings, lengths and "no doubles" property. The table shows how many symbols per message the search could fully explain:

The eyes look exactly like scrambled or random text here, so the test says nothing. That's not just a weak search. With the letters free, this cipher is flexible enough to explain almost any sequence. Counting information, random text only becomes unexplainable at roughly 65–75 symbols per message, far beyond what any search reaches.

What it means: under this model, the eyes can't be solved from the symbols alone. Something has to constrain the hidden text: a long enough guess (entry 11), or a model of the language, so that the search must also produce plausible text. Combining the GPU search with a language model is the most promising next step, but also the most expensive.

Also tried, with no gain: Google's OR-Tools CP-SAT solver (about as fast as the current one), and a decoder that assumes the two shuffles are known. That one can't yet tell true shuffles from random ones, so testing "seeded shuffle" ideas will need more work.

Entry 12 said the symbols alone can't settle anything, because the cipher can explain almost any sequence if the hidden text may be anything. So I made the search produce real language as well as a consistent key.

The language model. I trained letter statistics on 45 public-domain Finnish books from Project Gutenberg (10.6 million letters), plus 25 English books. The model predicts each letter from the four before it. On books it never saw, its average uncertainty is 2.2 bits per letter, about the same as choosing between five letters. Random letters would be about 4.5 bits.

The search. The GPU search from entry 12 now has to find shuffles, letter groups and a hidden text that both fit the symbols and read like the books. I tested it on fakes: nine messages with the eyes' lengths and shared openings, made from Finnish books the model never saw and encrypted with a random two-group key on 83 cards. So the right answer was known. Two checks came first. The right answer scores as a perfect fit at every length, and once the search holds it at 30 or more symbols per message, it keeps it.

Results on the 83-card fake. The search fully explained the first symbols of every message, but never with the right text:

Smaller decks tell the same story: a 41-card fake was explained up to 20 symbols, again with chance-level letters. So did a second 83-card fake whose messages continue naturally after their shared openings, and a sharper weighting of the language model.

How long the messages must be. Counting information, with these letter statistics only one answer should fit once the search covers about 37–42 symbols of every message. As a check, the same count says a known text pins the key at about 32 symbols per message. That agrees with entry 11's measurement (about 30).

What it means. The idea is sound in principle: the eyes have 99–137 symbols per message, plenty to single out the answer. But the search can't get anywhere near 40, and the language model isn't the weak link. Even handed the whole correct text, the GPU search can only find a matching key for 19 symbols. The exact solver is no quick fix: given the fake's correct text for the first 20, 25 or 30 symbols of each message, and left to find the letter groups itself, it still hadn't answered after an hour. With the full-length text and the groups given, it took 6.5 hours (entry 10). A working attack would have to find the key and an unknown text together, at about 40 symbols per message. I don't know how to build one. I doubt it's feasible if the shuffles are arbitrary.

On the real eyes the search reaches 20 symbols per message with Finnish and 21 with English, against 22 for random symbols. Like entry 12, that says nothing. The Finnish-looking text it produces is meaningless.

Known keys don't help this search either. Given the whole correct key, it reached 16 symbols per message. Given random shuffles, it sometimes failed within 4 symbols but once reached 17. So this search can't tell a right key from a wrong one. I also wrote a direct decoder that reads the messages off a proposed key. Even with the true key, it lost the right reading after about 12 symbols, about as far as random keys got. The deck's starting order is still unknown, and early on every new card is a free choice, so there are far more fluent wrong readings than it can track. Testing ideas about how the game builds its shuffles therefore needs a better decoder too.