Fandom

Uncovering Cicada Wiki

Gnu Privacy Guard

141pages on
this wiki
Add New Page
Talk0 Share

Two more readings:


The best explanation of it which I've seen can be found in Little Brother, a free novel by Cory Doctorow. It goes as such:

"What would you do if you found out you had a spy in your midst? You could denounce him, put him up against the wall and take him out. But then you might end up with another spy in your midst, and the new spy would be more careful than the last one and maybe not get caught quite so readily.
Here's a better idea: start intercepting the spy's communications and feed him and his masters misinformation. Say his masters instruct him to gather information on your movements. Let him follow you around and take all the notes he wants, but steam open the envelopes that he sends back to HQ and replace his account of your movements with a fictitious one. If you want, you can make him seem erratic and unreliable so they get rid of him. You can manufacture crises that might make one side or the other reveal the identities of other spies. In short, you own them.
This is called the man-in-the-middle attack and if you think about it, it's pretty scary. Someone who man-in-the-middles your communications can trick you in any of a thousand ways.
Of course, there's a great way to get around the man-in-the-middle attack: use crypto. With crypto, it doesn't matter if the enemy can see your messages, because he can't decipher them, change them, and re-send them. That's one of the main reasons to use crypto.
But remember: for crypto to work, you need to have keys for the people you want to talk to. You and your partner need to share a secret or two, some keys that you can use to encrypt and decrypt your messages so that men-in-the-middle get locked out.
That's where the idea of public keys comes in. This is a little hairy, but it's so unbelievably elegant too.
In public key crypto, each user gets two keys. They're long strings of mathematical gibberish, and they have an almost magic property. Whatever you scramble with one key, the other will unlock, and vice-versa. What's more, they're the only keys that can do this -- if you can unscramble a message with one key, you know it was scrambled with the other (and vice-versa).
So you take either one of these keys (it doesn't matter which one) and you just publish it. You make it a total non-secret. You want anyone in the world to know what it is. For obvious reasons, they call this your "public key."
The other key, you hide in the darkest reaches of your mind. You protect it with your life. You never let anyone ever know what it is. That's called your "private key." (Duh.)
Now say you're a spy and you want to talk with your bosses. Their public key is known by everyone. Your public key is known by everyone. No one knows your private key but you. No one knows their private key but them.
You want to send them a message. First, you encrypt it with your private key. You could just send that message along, and it would work pretty well, since they would know when the message arrived that it came from you. How? Because if they can decrypt it with your public key, it can only have been encrypted with your private key. This is the equivalent of putting your seal or signature on the bottom of a message. It says, "I wrote this, and no one else. No one could have tampered with it or changed it."
Unfortunately, this won't actually keep your message a secret. That's because your public key is really well known (it has to be, or you'll be limited to sending messages to those few people who have your public key). Anyone who intercepts the message can read it. They can't change it and make it seem like it came from you, but if you don't want people to know what you're saying, you need a better solution.
So instead of just encrypting the message with your private key, you also encrypt it with your boss's public key. Now it's been locked twice. The first lock -- the boss's public key -- only comes off when combined with your boss's private key. The second lock -- your private key -- only comes off with your public key. When your bosses receive the message, they unlock it with both keys and now they know for sure that: a) you wrote it and b) only they can read it.
It's very cool. The day I discovered it, Darryl and I immediately exchanged keys and spent months cackling and rubbing our hands as we exchanged our military-grade secret messages about where to meet after school and whether Van would ever notice him.
But if you want to understand security, you need to consider the most paranoid possibilities. Like, what if I tricked you into thinking that my public key was your boss's public key? You'd encrypt the message with your private key and my public key. I'd decrypt it, read it, re-encrypt it with your boss's real public key and send it on. As far as your boss knows, no one but you could have written the message and no one but him could have read it.
And I get to sit in the middle, like a fat spider in a web, and all your secrets belong to me.
Now, the easiest way to fix this is to really widely advertise your public key. If it's really easy for anyone to know what your real key is, man-in-the-middle gets harder and harder. But you know what? Making things well-known is just as hard as keeping them secret. Think about it -- how many billions of dollars are spent on shampoo ads and other crap, just to make sure that as many people know about something that some advertiser wants them to know?
There's a cheaper way of fixing man-in-the-middle: the web of trust. Say that before you leave HQ, you and your bosses sit down over coffee and actually tell each other your keys. No more man-in-the-middle! You're absolutely certain whose keys you have, because they were put into your own hands.
So far, so good. But there's a natural limit to this: how many people can you physically meet with and swap keys? How many hours in the day do you want to devote to the equivalent of writing your own phone book? How many of those people are willing to devote that kind of time to you?
Thinking about this like a phonebook helps. The world was once a place with a lot of phonebooks, and when you needed a number, you could look it up in the book. But for many of the numbers that you wanted to refer to on a given day, you would either know it by heart, or you'd be able to ask someone else. Even today, when I'm out with my cell-phone, I'll ask Jolu or Darryl if they have a number I'm looking for. It's faster and easier than looking it up online and they're more reliable, too. If Jolu has a number, I trust him, so I trust the number, too. That's called "transitive trust" -- trust that moves across the web of our relationships.
A web of trust is a bigger version of this. Say I meet Jolu and get his key. I can put it on my "keyring" -- a list of keys that I've signed with my private key. That means you can unlock it with my public key and know for sure that me -- or someone with my key, anyway -- says that "this key belongs to this guy."
So I hand you my keyring and provided that you trust me to have actually met and verified all the keys on it, you can take it and add it to your keyring. Now, you meet someone else and you hand the whole ring to him. Bigger and bigger the ring grows, and provided that you trust the next guy in the chain, and he trusts the next guy in his chain and so on, you're pretty secure.
Which brings me to keysigning parties. These are exactly what they sound like: a party where everyone gets together and signs everyone else's keys. Darryl and I, when we traded keys, that was kind of a mini-keysigning party, one with only two sad and geeky attendees. But with more people, you create the seed of the web of trust, and the web can expand from there. As everyone on your keyring goes out into the world and meets more people, they can add more and more names to the ring. You don't have to meet the new people, just trust that the signed key you get from the people in your web is valid.
So that's why web of trust and parties go together like peanut butter and chocolate."

That does a pretty good job of explaining why you can trust it almost entirely (if you want to go beyond a reasonable doubt, the entire source code is freely available). But this guide doesn't go anything into how exactly I'm meant to get from this:

-----BEGIN PGP SIGNED 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.

3301
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPBRz7AAoJEBgfAeV6NQkP1UIQALFcO8DyZkecTK5pAIcGez7k
ewjGBoCfjfO2NlRROuQm5CteXiH3Te5G+5ebsdRmGWVcah8QzN4UjxpKcTQRPB9e
/ehVI5BiBJq8GlOnaSRZpzsYobwKH6Jy6haAr3kPFK1lOXXyHSiNnQbydGw9BFRI
fSr//DY86BUILE8sGJR6FA8Vzjiifcv6mmXkk3ICrT8z0qY7m/wFOYjgiSohvYpg
x5biG6TBwxfmXQOaITdO5rO8+4mtLnP//qN7E9zjTYj4Z4gBhdf6hPSuOqjh1s+6
/C6IehRChpx8gwpdhIlNf1coz/ZiggPiqdj75Tyqg88lEr66fVVB2d7PGObSyYSp
HJl8llrt8Gnk1UaZUS6/eCjnBniV/BLfZPVD2VFKH2Vvvty8sL+S8hCxsuLCjydh
skpshcjMVV9xPIEYzwSEaqBq0ZMdNFEPxJzC0XISlWSfxROm85r3NYvbrx9lwVbP
mUpLKFn8ZcMbf7UX18frgOtujmqqUvDQ2dQhmCUywPdtsKHFLc1xIqdrnRWUS3CD
eejUzGYDB5lSflujTjLPgGvtlCBW5ap00cfIHUZPOzmJWoEzgFgdNc9iIkcUUlke
e2WbYwCCuwSlLsdQRMA//PJN+a1h2ZMSzzMbZsr/YXQDUWvEaYI8MckmXEkZmDoA
RL0xkbHEFVGBmoMPVzeC
=fRcg
-----END PGP SIGNATURE-----

To 'I can completely trust that this message was sent from who they purport to be'

The important bit to remember here is that with 3301's messages, they aren't encrypted. Anyone can view them. But here we have that weird block of text at the bottom, with some random weird characters that don't appear to make any sense. Effectively, this block of text is an encrypted version of the message inside. This means that when your crypto software performs a check on it, it will decrypt that text to find that a) the message was sent from the person you're checking it off with, and b) that they sent this message exactly.

If neither of these two tests return true, then the message was not sent from who this purports to be. 

Implementations

As with almost any kind of open source software, there's going to be multiple people who have forked and edited the source code to create their own version of it which can run on multiple platforms, support different GUIs, maybe even different encryption algorithms. The recommended implementations for each platform can be found below:

PC:

gpg4win seems to be the commonly accepted standard. But seriously, windows?
Cryptophane would be your other option, it does effectively the same thing

LINUX:

You should probably install the 'gpg' package from your package manager. Who needs GUIs anyway?
If not, the officially supported GUI is GPA

MAC:

GPGTools is your only option here. It provides an awesome GUI and some great integration with OSX, But seriously, OSX?

How to use

This, of course, is going to vary between different systems. Below I will provide the outlines of steps you can do, you should be able to find the corresponding stuff yourself in the programs.

1. GENERATE YOUR KEY

Generating a PGP key was required in 2013's puzzle. You should probably do that and upload your key to as many servers as possible. Probably post it in IRC too if you want.

2. GET 3301'S KEY

3301's key is officially available at MIT's keyserver . Import it to your software, you'll need it to verify any messages.

3. VERIFY ANY IMPORTANT MESSAGES

You should take a look through the writeups of the previous puzzles for signed messages. Attempt to verify these with your PGP software. For most, you should get a confirmation.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.