Skip to content
clickidy
🎯 ALL GAMES

READING · 17 MIN

THE PUZZLE
NOBODY TOOK CREDIT FOR.

It started with one image on an anonymous forum, no explanation, no sponsor logo, no prize. It ended up sending solvers chasing QR codes stapled to lampposts on four continents - and left behind a book that still isn't fully translated.

One image, no explanation ◢

On 4 January 2012, an image appeared on 4chan's /b/ board, posted by someone using the name “Cicada 3301,” stating that it was “looking for highly intelligent individuals” and hiding a message inside the image itself. Anyone who found it was led to another clue, then another - a puzzle chain that stretched on for weeks, reappeared in 2013, and again in 2014, then stopped setting new ones. No group or individual has ever come forward to take credit, and no sponsor, prize, or stated purpose was ever confirmed.

Steganography, real ciphers, and an invented alphabet ◢

Each stage combined genuine techniques rather than made-up ones: steganography (data hidden inside ordinary-looking image files), classical substitution methods - solvers reported stages that reduced to straightforward Caesar shifts and Atbash-style mirrors once the hidden layer was stripped away - and book ciphers keyed to real, obscure texts (T. S. Eliot's poetry and Kabbalistic writings both turned up as references). The puzzle also invented its own system, the “Gematria Primus,” a rune-styled alphabet mapping each letter to a prime number, used throughout the later stages as a private key of sorts.

Posters in eleven cities, on four continents ◢

Solving online clues eventually surfaced GPS coordinates, and the coordinates led to real physical posters - bearing a cicada image and a QR code - stapled up in cities including Seattle, Miami, New Orleans, Paris, Warsaw, Sydney, and Seoul, all appearing within the same short window. Submitting a correct online solution required a working PGP key, and later stages pointed solvers toward Tor hidden services - a level of technical and logistical coordination that fuelled years of speculation the puzzle was a recruitment test run by an intelligence agency, a private security firm, or a cryptography-focused collective. None of those theories has ever been confirmed.

Liber Primus: the book that's still mostly unread ◢

The 2012 and 2013 puzzle chains were both eventually solved in full by the collaborative effort of thousands of solvers organising on forums and a dedicated wiki. The 2014 chain, though, surfaced a 58-page illustrated text known as Liber Primus - Latin for “the first book” - written entirely in the puzzle's own invented rune-and-number alphabet. Only a handful of its pages have been translated with any confidence in the years since; most of the book remains unread. No new puzzle chain has appeared since 2014, but the source itself didn't vanish: signed messages kept turning up under the same PGP key, the last of them dated 4 April 2017. That signature is the test the puzzle-solving community still uses - anything “Cicada” that key never signed gets treated as an unrelated copycat.

Play the ciphers in this story

CODESCaesar Cipher Decoder

Shift the alphabet to encode - or brute-force all 25 to crack it.

SHIFT 1-25 · ROT13CODESAtbash Cipher Decoder

Mirror the alphabet - A becomes Z, B becomes Y.

A↔Z MIRRORCODESCodes & Ciphers

Morse, binary, Caesar, more - encode anything.

10 CIPHERS

More Codes & Ciphers history →

WHAT THE RECORDS SHOW ◢

Anyone could post a message signed "3301". The way people told the real ones apart was arithmetic, not judgement: a genuine message carried an OpenPGP signature made by a 4096-bit RSA key created on 5 January 2012 at 03:39:43 UTC, and anybody with the free tools could check it in a second. The key is still published. The messages are still archived. The signatures still verify today.

That is an unusual thing for an anonymous source to leave behind. It means the authorship question splits cleanly in two, and only one half is unanswered.

Key Takeaways

  • The key is RSA 4096, fingerprint 6D85 4CD7 9333 22A6 01C3 286D 181F 01E5 7A35 090F, user ID "Cicada 3301 (845145127)".
  • The first signature was made 380 seconds after the key itself, at 03:46:03 UTC on 5 January 2012.
  • A "good signature" proves the text was not altered by so much as one letter, and nothing at all about who typed it.
  • Trailing spaces are stripped before hashing (RFC 4880, Section 7.1), so one signature legitimately fits several differently-spaced copies of the same message.
  • The identifier Cicada told people to check, 7A35090F, is the shortest and weakest one the format offers.

What does a Cicada 3301 signature actually prove?

Two separate things, and it is worth keeping them apart.

It proves the message is byte-exact. The signature is computed over the message text, so altering the text breaks it. Changing a single letter of the April 2017 message, "Beware false paths" to "Beware false pathz", turns a good signature into a bad one and nothing else in the file has to change.

It proves the message came from whoever holds the private half of that one key. That is a statement about a key, not about a person, a group, or a country. The verifying software says so out loud: alongside "Good signature", GnuPG prints "There is no indication that the signature belongs to the owner."

Everything else people wanted to know sits outside what the mathematics can deliver.

Where the Cicada 3301 key came from, and how you know you have the right one

The key was published on the MIT keyserver and announced in a signed message that begins:

- From here on out, we will cryptographically sign all messages with this key.

It is available on the mit keyservers.  Key ID 7A35090F, as posted in a2e7j6ic78h0j.

Shown exactly as the signed file holds it, down to the two spaces after each full stop. That stray hyphen at the start is not a typo. Under RFC 4880, Section 7.1, a signing tool "SHOULD dash-escape lines commencing 'From' followed by a space", so the line was rewritten before signing and any verifier strips it back off.

This announcement carries the earliest signature in the whole archived set, timestamped 03:46:03 UTC on 5 January 2012, six minutes and twenty seconds after the key's own creation time of 03:39:43 UTC. Both figures are stored inside the files themselves, and both come out of any OpenPGP tool.

The identity of a key is its fingerprint, which is a hash of the public key material rather than a name anyone chose. RFC 4880, Section 12.2 defines it: "A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint."

Because it is derived from the key and not asserted about it, copies from unrelated services can be compared. Fetching the key from keys.openpgp.org, from keyserver.ubuntu.com, and from an archived April 2016 capture of the MIT keyserver returns the identical fingerprint above and the same creation date of 5 January 2012. The imported key also carries a second, encryption-only subkey, fingerprint DEC5 7731 ACCB FD11 EEBA 1343 4D39 0ECF 671D DEB1.

The user ID is the odd part. It is not an email address but a number: 845145127. That number factors into 3301 times 503 times 509, and all three of those are prime. No signed message explains the choice, and nothing in the public record does either, so it is best treated as a checkable curiosity rather than a clue with a known meaning. If you want to try picking apart the sort of thing it might have been, the cipher identifier is the usual first move.

Checking a message yourself takes four steps.

  1. Fetch the public key by its full forty-character fingerprint from a keyserver such as keys.openpgp.org or keyserver.ubuntu.com.
  2. Import it into a fresh keyring, so nothing else on your machine can be confused for it.
  3. Run a verify against the message file and read the result.
  4. Compare the fingerprint the tool reports against the full forty characters, not against the eight-character short form.

A genuine message reports a good signature from key 181F01E57A35090F. It will also report that the key is not certified by anyone you trust, which is correct and unavoidable, because no one can vouch for an identity nobody knows.

Why one signature legitimately fits several different files

Among the archived clearsigned messages there are twenty-one files but only sixteen distinct signatures. Four groups of files share a signature between them. Three separate 2014 files carry one identical 543-byte signature packet, and three further pairs share a packet each, one pair from 2012, one from 2013 and one from 2017. Five collapses, twenty-one files, sixteen signatures. The per-year breakdown is in the table below. The files within each group genuinely differ, byte for byte. They still verify.

This is not sloppiness in the archive. It is a rule in the format. RFC 4880, Section 7.1 requires that trailing whitespace, meaning spaces (0x20) and tabs (0x09), "at the end of any line is removed when the cleartext signature is generated." Lines that differ only in the spaces hanging off their right-hand ends hash identically, so one signature covers all of them. Padding every line of the April 2017 message with three extra spaces leaves it verifying perfectly.

The current OpenPGP standard treats this as a known defect rather than a feature. RFC 9580, Section 7.3, published in 2024, warns that "the Cleartext Signature Framework will fail to safely round-trip any textual stream that may include semantically meaningful whitespace", and advises using a different kind of signature for such files.

The same section notes something else visible in Cicada's own files: "an attacker can include additional text in the Hash header, which may mislead the user into thinking it is part of the signed text." The armour headers above a signature are decoration. The April 2017 message carries the line "Version: CicadaPG v.3301", which looks like a bespoke tool and is not covered by the signature at all. Rewriting it to something else entirely leaves the signature good. RFC 9580, Section 6.2.2.1, says implementations "SHOULD NOT emit this key and its corresponding value" precisely because it is unverifiable metadata.

Why one archived message does not verify

One of the twenty-one archived files fails. The January 2013 message opening "Welcome again." and continuing "Here is a book code. To find the book, break this riddle:" reports a bad signature rather than a good one.

The cause is visible in the raw bytes and is not sinister. The file is missing the blank line that has to separate the armour headers from the message text, so the text being hashed is not the text that was signed. Inserting that one blank line, a two-byte change, restores it: the same file then reports a good signature made at 04:33:29 UTC on 3 January 2013.

That is the useful demonstration in the whole story. The failure looked exactly like a forgery and was a transcription slip, and the way you tell those apart is not by arguing about the archive's reputation but by repairing the copy and re-running the check. The signature does not care where the bytes were downloaded from.

The identifier Cicada published is the weakest one available

Both the first announcement in 2012 and the last message in 2017 point readers at the same eight characters. The 2017 text reads in full:

"Beware false paths. Always verify PGP signature from 7A35090F."

Eight hexadecimal characters is 32 bits: the tail end of the 64-bit Key ID the standard defines, and the last fifth of the 160-bit fingerprint. Both OpenPGP specifications warn about relying on it. RFC 4880, Section 12.2 notes that "it is possible for there to be collisions of Key IDs", meaning two different keys with the same Key ID. RFC 9580, Section 3.3, is blunter: "Implementations SHOULD NOT assume that Key IDs are unique. A fingerprint is more likely to be unique than a Key ID."

So the advice as written is checkable but under-specified. Somebody who obtains a key whose short ID also ends 7A35090F, uploads it, and signs an imitation would satisfy a reader who only compares those eight characters. Comparing the full forty-character fingerprint is what closes that gap, and it costs nothing extra.

What SHA-1 does to the guarantee

Every signature from 2012 through 2015 uses SHA-1 as its digest. The two April 2017 files use SHA-512. That upgrade landed in the right decade.

Signatures made Files archived Distinct signatures Digest
2012 7 6 SHA-1
2013 5 4 SHA-1
2014 6 4 SHA-1
2015 1 1 SHA-1
2017 2 1 SHA-512

Grouping is by the signature timestamp inside each file, which is not always the year the file is named for.

SHA-1 was already weakening throughout the period the puzzle ran. In 2020, Gaëtan Leurent and Thomas Peyrin presented the first practical chosen-prefix collision against it at USENIX Security, and applied it directly to PGP: they built "a pair of PGP/GnuPG keys with different identities, but colliding SHA-1 certificates", so that a certification of one key transferred to the other. Their attack took "two months of computations using 900 Nvidia GTX 1060 GPUs", and they priced a rented chosen-prefix collision at about US$45,000. Their conclusion was that "SHA-1 signatures now offer virtually no security in practice". The resulting GnuPG issue is tracked as CVE-2019-14855.

Two caveats keep this in proportion. First, that attack forges certifications, the statements keys make about identities, and it requires the attacker to construct both colliding documents in advance. It does not let anyone take an existing Cicada message and produce a second, different message with the same signature. Second, the V4 fingerprint that identifies the key is itself a SHA-1 hash, per RFC 4880 Section 12.2, which is why the newer standard introduced a version 6 key format with a SHA-256 fingerprint in Section 5.5.4.3.

The practical position is that these signatures were made long before the cheap-collision era and are checked today against a key whose fingerprint has been stable across independent copies for over a decade.

What the signed Cicada 3301 record does not say

The archived signatures run from 5 January 2012 to 4 April 2017, a span of about five years and three months, all made by the same key. The record includes a signed reply from 28 July 2015 to what it calls the claims of "some news organisations", which states: "We do not engage in illegal activities. We are not associated with this group in any way."

Not one of those messages names a person, an organisation, a country or a purpose. The signatures establish continuity, which is a real and unusual thing to have from an anonymous source, and they establish nothing about identity.

Two further gaps deserve stating rather than filling. The signature timestamp is a field the signer supplies. RFC 4880, Section 5.2.3.4, defines it only as "the time the signature was made" and requires it in the hashed area, meaning nobody else can alter it after the fact, but the value still comes from the signer's own clock. And a private key can be copied or handed on, so even perfect continuity of key control does not establish continuity of the people using it.

Nor do the endorsements help. The copy of the key served by keyserver.ubuntu.com in August 2026 carries certifications from 301 distinct key IDs; the archived April 2016 MIT keyserver page already showed 216. Anyone can sign anyone's key. Those certifications say that hundreds of strangers believed this key belonged to "Cicada 3301", a name that no independent record ties to anybody, which is a measure of enthusiasm rather than of evidence.

Frequently asked questions

How can I check a Cicada 3301 message myself?

Fetch the public key by its full fingerprint from a keyserver such as keys.openpgp.org or keyserver.ubuntu.com, import it into any OpenPGP tool, and run a verify against the message file. A genuine message reports a good signature from key 181F01E57A35090F. Do the comparison on the full forty-character fingerprint rather than the eight-character short form, because the standards say short IDs can collide. Expect the tool to add a warning that the key is not certified by anyone you trust. That warning is correct and unavoidable here.

Does a valid signature prove who Cicada 3301 is?

No, and this is the most common misreading of what the check does. A valid signature proves that the holder of one specific private key signed exactly that text, and that the text has not been edited since. It carries no information about the holder's name, nationality, employer or number. Private keys can be copied or handed on, so it does not even guarantee that the same people were behind two messages years apart. The identity question is untouched by the cryptography and remains unanswered by any primary source.

Why do two copies of the same message look different but both verify?

Because trailing spaces and tabs at the end of each line are stripped before the text is hashed, a rule written into RFC 4880 at Section 7.1. Copies that differ only in that invisible padding produce the same digest, and therefore accept the same signature. That is why three separate archived 2014 files share one identical 543-byte signature packet. Anything that changes a visible character breaks the signature immediately, so the tolerance is much narrower than it first sounds.

What was the last verified message?

The most recent signature in the archived set was made on 4 April 2017 at 23:23:28 UTC. It covers a two-line text reading "Beware false paths. Always verify PGP signature from 7A35090F." Later material has circulated under the name, but the test for it is the one the 2012 announcement set out and the 2017 message repeated. It either carries a signature that verifies against this key or it does not, and no primary source offers any other way of confirming it.

Is SHA-1 a problem for the older messages?

It is a genuine weakness in the algorithm rather than a demonstrated break of these particular files. The 2020 USENIX Security paper by Leurent and Peyrin showed a practical chosen-prefix collision, and used it to transfer a PGP certification between two keys with different identities. That is why modern tooling rejects SHA-1 certifications under CVE-2019-14855. The attack needs both colliding documents to be built by the attacker in advance, so it does not retroactively let anyone substitute new text under an existing 2012 signature. The April 2017 message moved to SHA-512 in any case.

Every signature timestamp, fingerprint, packet size and count above was read out of the message files with GnuPG 2.5.21 on 10 August 2026, using a keyring containing only this key. Any reader with GnuPG can repeat it.

Fancy something you can actually break? The rest of the ciphers are next door, and if you would rather stay with the ones nobody has finished, Kryptos and the Voynich manuscript are still open.

Sources