# My PGP Key

You *must:*

(1) verify that the public key listed bellow really belongs to me (why?)

(2) Sync your keyring with a public key server in order to receive updates about my key (why?)

My PGP key is 0x574aae842882b369 (technical details)

# PGP Explained

We'll start our explanation of PGP by explaining basic cryptographic concepts. The explanation is very basic, and meant to give some notions about cryptography to readers that have never heard of cryptography before. If you already know a thing or two about general cryptography, you can skip this part.

###### Cryptography

In order to explain the basics of cryptography, we will use a fictional situation and fictional characters. Imagine the following situation:

We have two persons: **Alice** and **Bob**. Alice knows Bob, and Bob knows Alice. They actually know each other very well: they are a couple and they're madly in love.

There also is a third person: **John**. Alice, nor Bob know John. John is an evil person who is in love with Alice. John can't stand that Bob sends messages to Alice, and John wants to read every message that is sent to Alice.

Imagine John is able to eavesdrop and manipulate the internet connection of Alice. John is therefore able to see every message that is sent and received through the internet connection of Alice.

When Bob sends a *message* to Alice (e.g.: the message "**anniversary**"), John is able to read that message. This situation is illustrated in picture 1 (situation A).

Bob doesn't like that idea, so Bob decides to **encrypt** his message to Alice: he converts the message "anniversary" (which is called the **plaintext**) to another message (called the **cipher text**), in such a way that only Alice can read the message. This process of encoding the message in such a way that only Alice can read it is called encryption.
In order for Alice to be able to read the message, Alice must **decrypt** the cipthertext into the plaintext.

When Bob sends the *encrypted message* to Alice, John isn't able to derive the plaintext message (anniversary) from the encrypted message. John is able to see that an encrypted message is sent, but he has no idea what the contents of the message is. This situation is illustrated in picture 1 (situation B).

Picture 1: Bob sends an unencrypted and an encrypted message to Alice

In the next paragraph, public keys are explained with the help of our characters **Tommy** and **Joe**. Don't worry, we will back with Alice and Bob soon!

###### Public keys

In the previous paragraph we have explained that Bob can encrypt his message(s) to Alice. To encrypt something, Bob needs an **encryption algorithm** and a **key**.
The encryption algorithm is a sequence of calculations that takes a plaintext and a key as input. The output of the algorithm is the cipher text.

There are two categories of encryption algorithms: **symmetric encryption algorithms** and **asymmetric encryption algorithms**. Symmetric encryption algorithms use the same key for encryption and decryption. The key used for encryption/decryption (the **symmetric key**) can only be known by the parties that need to be able to encrypt/decrypt the message.
An asymmetric encryption algorithm uses two separate keys: one key is used to encrypt a plaintext, the other key is used to decrypt the cipher text. When using asymmetric encryption, one decides which key is kept secret (called the **private key**), the other key is made available publicly (called the **public key**).

When two persons want to exchange encrypted messages, they can use either symmetric or asymmetric encryption to encrypt/decrypt their messages.

When both persons use a *symmetric encryption algorithm* to secure their messages, both persons should already possesses the (same) symmetric key. When only one of the two persons possesses the symmetric key, the key owning person could send the other person the key,
but that is not a good idea given the fact that the message containing the key could be intercepted. (Remember: we assume that all communications can be intercepted, this assumption made us use encryption to exchange messages in the first place!).

Picture 2 (left) illustrates an example where our characters Tommy and Joe use symmetric encryption to secure their messages. Tommy and Joe should already have agreed on a symmetric key before sending their messages via the internet (e.g. by discussing the key in a real life conversation that nobody else can eavesdrop on).

When the communicating parties use *asymmetric cryptography*, the exchanged keys (the public keys) don't need to be exchanged in a secure way, because they are not secret. The sender of the message does not even need to contact the message recipient in order to get his public key because, as stated above, the public key is made available publicly (e.g. by publishing it on a website).
For message exchanging purposes, we will chose the *public key* of the message recipient as the key to *encrypt* the message (the plaintext) and the *private key* of the message recipient as the key to *decrypt* the cipher text. This way anyone can send an encrypted message to a specific person, but only the intended recipient can decrypt the message.

Picture 2: Symmetric encryption (left), asymmetric encryption (right)

###### Using the right public key

Now we know what asymmetric encryption is, let's get back to Alice and Bob. By now, you should understand that Alice and Bob can secure their messages by using asymmetric cryptography, also known as **public key cryptography**. Alice and Bob are able to look up each other's public key, because their public keys are presumed to be published publicly.

The key publication can be achieved in multiple ways. Alice and Bob can for example display their public key on their website or publish it on the server of a third party that hosts public keys (called a **public key server**). It doesn't matter which method Alice and Bob use to make their public key publicly available, but it is very important
that no one else but the key owner can change the value of the published key. We'll call in the help of our character John to illustrate why it is so important that the integrity of the public key is assured.

When Bob uses Alice's public key to encrypt his message, John can't make sense of the encrypted message. This situation is illustrated in picture 3 (situation 1).

John however is a smart man, and realizes that if Bob encrypts his message(s) to Alice using *John's public key*, he is able to derive the plaintext. John can trick Bob in using his public key by changing the displayed public key on Alice's website (we stated in the first paragraph that John is able to manipulate the internet connection of Alice, thus John is also able to take control of Alice's website).

If Bob then sends an encrypted message -encrypted with John's public key- to Alice, John can intercept the message, decrypt the message with his private key, re-encrypt the message with Alice's public key, and forward the re-encrypted message to Alice.
Alice will be able to decrypt the message because her public key is used, but Alice will not know John has tampered with it. (That is, not by just inspecting the message). This attack is called a **man-in-the-middle attack** and is illustrated in picture 3 (situation 2).

Picture 3: Man in the middle attack. John can decrypt Bob's message because

Bob uses John's public key to encrypt his message.

In the next paragraph, we will explain how the trust that you have established the correct key can be increased (i.e. how can Bob be more confident that Alice's public key really belongs to Alice, and not to John).

###### Signing and key revocation

A commonly used method to prevent the forgery of keys is the **signing of keys**. Signing is used for demonstrating the authenticity of a digital message or public key. In the public keys paragraph we stated that in public key cryptography one can *encrypt* a message with the *public key* of the message recipient, and *decrypt* a received message with his/her *private key*.
Signing is actually the same as encrypting, with the difference that in signing the user *encrypts* the plain text with a *private key* instead of encrypting the plain text with a public key. The process of encrypting a digital message/key
using a private key, with the purpose of demonstrating the authenticity of a digital message or public key, is called signing. Even though signing and encrypting both transform a plain text into a cipher text using a certain key, signing is not called encryption, to denote the difference in use of the public and private keys in the encryption process. The private key used for signing a message differs from the private key used to decrypt a message.
Two communicating parties will thus each have a key pair to encrypt/decrypt and a key pair to sign:

- A public key to
*encrypt*messages - A private key to
*decrypt*messages - A public key to
*verify*signatures - A private key to
*sign*messages

Bob can ask one or multiple trusted parties to sign his public encryption key. The parties (e.g. **Legolas** and **Aragorn**) will sign Bob's public key using their private signing keys.
A third party can verify the signatures using Legolas' and Aragorn's public signing keys. When Alice receives a forged public key, she will notice this because the key will not be signed by a party that is trusted by her.
This situation is illustrated in picture 4.

Picture 4: Bob and John get their public keys signed. Alice only trust signatures from Aragorn

and will revoke public keys that aren't signed by Aragorn.

A public key is usually published by means of a **certificate**. The certificate includes the name of the public key owner, the public key itself, and a validity date. The validity date indicates the final date until a key can be trusted.
After that date, a new certificate should be used. When a user loses a private key for some reason, he can **revoke** his **certificate**. This revocation indicates that the public key in the certificate should no longer be trusted.
A user can only notice the certificate revocation if he is synchronized with a public key server.

# Why PGP?

Philip Zimmermann (inventor of PGP): Why I wrote pgp

Glenn Greenwald (Pulitzer Prize winner for journalism): Why privacy matters

Trina J. Magi: Why does privacy matter?