Threat Stack Blog and Cloud Security News

Continuous security monitoring for your cloud.

Cicadas & Security, Part 2: When a Verified PGP Key Takes You on a Trip to the Desert

by Toni Noble Apr 19, 2017 11:45:13 AM

Cicadas Security Part 2 Blog Banner.png

Since our first installment in this series, there has been little excitement around the Cicada 3301 community, as a verified clue has yet to surface online or, as far as we know, in real life. A user going by the handle CicadaDave came forward on Reddit claiming to be part of a four-person team behind Cicada. His original post has since been deleted, but a lone comment remains on the account stating “I am Michael Cicada, aka Cicada Dave. We created Cicada 3301 as a joke between 4 bored MIT students. I am on Facebook if you have questions.”

Reddit users immediately sought verification of the user’s claims, but he could not provide any. CicadaDave alleged that their system administrator had accidentally deleted the virtual machine they were utilizing, and therefore he had no access to the PGP key that Cicada promised to use in all future communications. This, of course, was not believed by those solving the puzzle, and a quick look into the Michael Cicada Facebook account shows that this person is simply another Cicada enthusiast.

At the beginning of January 2017, a post was made on 4chan’s /x/ (paranormal) board with the following image:

Cicada 1.png

When opened in a text editor, the following can be found at the bottom of the file:

35.285827, -115.68463 popfilesxuru7lsr.onion/~truth7/7111317192329.png

This brought up several questions: Why was there no PGP signature? Why would Cicada put one clue, let alone two clues, essentially in plain sight? What is located at the provided coordinates? While we can only ascertain where the provided latitude and longitude point to, we can be fairly sure that this was not Cicada because of the lack of a PGP signature. Is it possible that Cicada lost access to their private key? Of course, but there are other ways for Cicada to communicate information and have it be trusted (like their Twitter account).

Consider this scenario: You and your friend want to communicate privately, so while in person, you set up and exchange PGP keys. All communications and files received from your friend are signed with their private key until one day when you receive one that isn’t. At first glance it appears as though it’s from them, but how can you be sure? After calling your friend, they tell you that they bought a new laptop and hadn’t imported their keys yet. You thoroughly scold them for not being secure and move on with your day. Now replace that friend with a person, or group of people, that you’ve never contacted directly or met in person. How would you trust that an unsigned file is from them? Simple: you wouldn’t.

In order to verify Cicada’s PGP signature on their supposed posts, you would need to import the public key that they previously provided. With applications like Gpg4win and GPG Suite it’s easy to generate, import, and manage your keys, but we’ll focus on utilizing gnupg2 on the command line. You can install gnupg2 however you prefer, but the simplest way would be by running sudo apt-get install gnupg2 or yum install gnupg2. Once gnupg2 is installed, you can search for Cicada’s public key on the MIT key servers using the short version of their key fingerprint:

# gpg --keyserver --search-keys 7A35090F
gpg: searching for "7A35090F" from hkp server
(1)    Cicada 3301 (845145127)
	  4096 bit RSA key 7A35090F, created: 2012-01-05
(2)	Cicada 3301 (845145127)
	  4096 bit RSA key 7A35090F, created: 2012-01-05
Keys 1-2 of 2 for "7A35090F".  Enter number(s), N)ext, or Q)uit >

You can query the key server for other strings, such as an email address, but beware that it is a less secure way of locating the correct public key you’re searching for.

Enter 1 and hit return and Cicada’s key will be imported:

Keys 1-2 of 2 for "7A35090F".  Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key 7A35090F from hkp server
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 7A35090F: public key "Cicada 3301 (845145127)" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
Now let’s verify that this is actually Cicada by checking the full key fingerprint instead of the short version, or key ID, which can be faked:
# gpg --fingerprint 7A35090F
pub   4096R/7A35090F 2012-01-05
      Key fingerprint = 6D85 4CD7 9333 22A6 01C3  286D 181F 01E5 7A35 090F
uid                  Cicada 3301 (845145127)
sub   4096R/671DDEB1 2012-01-05
To test that we are able to verify Cicada’s messages, let’s now check their first signed communication by running gpg, copy/pasting the message, and hitting CTRL + D:
# gpg
gpg: Go ahead and type your message ...
Hash: SHA1

- 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.

Patience is a virtue.

Good luck.

Version: GnuPG v1.4.11 (GNU/Linux)

e2WbYwCCuwSlLsdQRMA//PJN+a1h2ZMSzzMbZsr/YXQDUWvEaYI8MckFrom 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.

Patience is a virtue.

Good luck.

gpg: Signature made Thu 05 Jan 2012 03:46:03 AM UTC using RSA key ID 7A35090F
gpg: Good signature from "Cicada 3301 (845145127)"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6D85 4CD7 9333 22A6 01C3  286D 181F 01E5 7A35 090F

It is also possible to decrypt a message by running gpg -d <filename> .

You can follow the same steps to import other public PGP keys from the MIT key server, or if you are given a public key file, you can import it by running gpg --import <filename> .

Now you’re ready to verify PGP signatures and encrypt files, but how is anyone going to verify that your messages are from you or send you messages only you can decrypt? To start, let’s create a key by executing gpg --gen-key. You will be prompted with several questions regarding key size, expiration date, your information, and a passphrase. If you reach the following error, then try some long-running commands in the background:

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy!
Once your key has been generated, you’ll receive a message like this:
gpg: key FEFE7634 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/FEFE7634 2017-04-14
      Key fingerprint = 40BC C9EE DCDF 1FA8 FF3C  C40B E6B8 DB76 FEFE 7634
uid                  Toni Noble (Beep Boop I Am A Computer) <>
sub   2048R/65C78825 2017-04-14
At this point you should generate a revocation certificate so you don’t end up in situations like CicadaDave’s where your private key is lost or compromised:
$ gpg --gen-revoke --armor --output=RevokeCert.asc 
You will be prompted with a few questions and have to enter your passphrase. Once the revocation certificate is generated, you should move it to a secure place because, just like your private key, you do not want this getting into anyone else’s hands. Being able to revoke your key provides further reason to doubt Cicada-esque posts that are not signed with their PGP key. Now let’s export our key so we can share it with others:
$ gpg --output MyPublicKey.gpg --export 
This can be uploaded to the MIT key servers for easy public access or emailed to a friend. To upload your public key to the MIT key server without leaving the command line, run the following:
$ gpg --keyserver --send-keys 
gpg: sending key FEFE7634 to hkp server
Now let’s actually encrypt something and verify that it was signed by us:
$ gpg --encrypt --sign --armor -r  SuperSecretFile.txt

$ gpg SuperSecretFile.txt.asc

You need a passphrase to unlock the secret key for
user: "Toni Noble (Beep Boop I Am A Computer) <>"
2048-bit RSA key, ID 65C78825, created 2017-04-14 (main key ID FEFE7634)

gpg: encrypted with 2048-bit RSA key, ID 65C78825, created 2017-04-14
      "Toni Noble (Beep Boop I Am A Computer) <>"
gpg: Signature made Fri 14 Apr 2017 08:20:22 PM UTC using RSA key ID FEFE7634
gpg: Good signature from "Toni Noble (Beep Boop I Am A Computer) <>"

For this example I was the only recipient, since I was the one who wanted to decrypt the message. You can list further recipients by specifying  -r <recipients_email_or_key_ID>.  If you do not include yourself as a recipient, then you will not be able to decrypt the file.

With PGP set up, we’re ready to verify all further clues from Cicada from the safety of our computer. But what about those latitude and longitude coordinates? The ones provided from the unsigned image point to the Mojave phone booth in the middle of the desert, but since we can’t verify that the image is from Cicada, no one will be traveling there hunting for clues any time soon. In past years however, Cicada has utilized both phones and clues in physical locations.

In the 2012 and 2013 games, physical flyers were discovered in numerous locations around the globe. After following a book code, the phone number (214) 390-9608 (now out of service) was provided, and calling it gave the listener the following message:

“Very good. You have done well. There are three prime numbers associated with the original final.jpg image. 3301 is one of them. You will have to find the other two. Multiply all three of these numbers together and add a .com to find the next step. Good luck. Goodbye.”

The dimensions of the original image were 509x503, which gives us 845145127 when multiplied by 3301. The same number can be found attached to Cicada’s PGP key, and navigating to provided another image of a cicada along with a countdown. After performing an OutGuess on the image, a signed message was discovered that asked solvers to be patient. Shortly thereafter, the website updated with a couple of sets of coordinates and a new image that, when OutGuess was used on it, presented more locations by latitude and longitude.

Flyers featuring a picture of a cicada and a QR code were posted around the globe in places such as Paris, Warsaw, and Miami. This drove some participants out of their homes in search of clues, while others had to rely on connecting with people online in order to obtain the latest information. Cicada copycats have yet to fool people into believing they are who they claim to be, let alone prompt them to drive into the Mojave desert — yet some people still attempt to solve their puzzles. When asked why they bother, some say it’s good practice, while others read deeper into the fake messages provided.

Is it fun? Sure. Is it safe? Maybe. Is it secure? Of course not. Using tools such as PGP and OutGuess mitigates some risk, but there’s always the chance of danger whether in real life or online, and that’s part of the charm of mysterious alternate reality games — Cicada 3301 or not.

Topics: Cicada 3301, Encryption, Alternate Reality Games, ARG, PGP, PGP Tutorial

Toni Noble

Written by Toni Noble

Toni is a QA Engineer at Threat Stack, Inc. responsible for developing and executing tests on all aspects and components of distributed systems to ensure end-to-end quality. She has six years of experience in QA and has worked on various platforms, including numerous distributions of Linux and many mobile operating systems.

Subscribe via email:

Posts by Topic

see all